Cover responsibilities, not titles
AI Agent Development Team Structure
Build an agent delivery team around business decisions, engineering, domain review, evaluation and operations, with a worked ownership map.
The right AI agent development team is a set of covered responsibilities, not a fixed headcount or a collection of impressive job titles. Someone must own the business decision, someone must build reliable software, someone must judge behaviour against real cases and someone must operate the result. Several responsibilities can sit with one person when the scope permits; none should disappear between the customer and supplier.
This guide is for a sponsor assembling an internal team or assessing a delivery partner. Its illustrative workflow is a field maintenance handover assistant. The assistant collects approved service records, summarises unresolved issues and prepares a shift handover. It does not certify equipment condition or replace the qualified person responsible for maintenance decisions.
Organise around decisions that require an owner
Start with the decisions the project must make: which work is supported, which sources are authoritative, what actions are allowed, what evidence permits release and who responds when something goes wrong. Assign one accountable owner to each decision. Contributors can be numerous, but a decision without a clear owner will tend to recur rather than resolve.
NIST's AI RMF calls for documented roles, responsibilities and communication lines. The allocation proposed here is an operating design, not a certification model. See the AI RMF Core.
For the maintenance example, the operations owner decides whether the handover is useful. The maintenance authority decides what conclusions require a qualified reviewer. The system owner authorises access to service records. An engineer should not silently inherit those decisions merely because they can implement a tool quickly.
The business owner defines what useful completion means
The business owner maintains the scope, prioritises trade-offs and accepts the operational outcome. They need access to real users and enough authority to resolve competing requests. A sponsor who appears only at the final demonstration cannot reliably adjudicate months of unresolved workflow assumptions.
In the handover assistant, the owner specifies whether completion means a draft prepared, a supervisor-approved handover or a published shift record. These are different operating obligations. They also define what happens to cases the agent cannot process, so that automation does not quietly transfer work into an unowned exception queue.
This role should preserve the distinction between benefit hypotheses and observed results. If reduced preparation effort is the goal, decide how it will be measured including review and correction. The owner should not accept a generated document count as proof of a useful productivity gain.
Domain reviewers supply judgement and difficult cases
A domain reviewer explains the meaning of the records, identifies consequential omissions and judges whether a handover supports the next shift. They should help select cases with incomplete notes, unresolved work and contradictory status updates. Training only on tidy examples hides the workload that most needs careful handling.
Review capacity must be planned as real work. Reserve time to inspect early outputs and clarify ambiguous rules. The engineering team cannot compensate for absent domain review by producing more variations of a prompt. A documented response window and an alternate reviewer can prevent avoidable waiting.
For bilingual operations, include reviewers who understand both the language and the maintenance terminology. A general translator may judge fluency without noticing that a phrase changed “inspection pending” into “inspection completed”. Assign responsibility for the shared terminology and for meaning-preserving treatment of names and equipment identifiers.
Engineering covers the system around the model
The technical lead connects requirements to architecture and makes trade-offs explicit. Application engineers implement identity, interfaces, state, commands and integration behaviour. Model and retrieval work may be performed by a specialist or by the same engineers, depending on the actual difficulty. The important question is which capability is demonstrated, not whether a particular title appears on an organisation chart.
For the handover assistant, the engineer needs to preserve the relationship between the asset, service record and shift. They must distinguish a saved draft from a published handover and handle interrupted operations. The architecture guide explains these component responsibilities.
Do not require a research team by default when the project uses existing models and ordinary application components. Equally, do not assume prompt writing alone covers integration, testing and operations. Hiring should follow the difficult work identified in discovery, including data repair or interface design when those are the limiting factors.
Evaluation needs enough independence to challenge the build
An evaluation owner maintains cases, scoring rules and release evidence. Developers should test their own changes, but the same person who tunes against every example should not be the only source of acceptance judgement. A domain reviewer or quality lead can provide an independent perspective appropriate to the project's consequence and size.
Keep test design connected to the real task. For the handover assistant, a missing unresolved issue may matter more than stylistic similarity to a reference summary. Evaluation should inspect source support, omissions, access boundaries and the final workflow state. The evaluation guide covers these distinctions.
Give the evaluation owner authority to raise a release-blocking issue. Otherwise, testing becomes a presentation activity that records concerns without changing the decision. Specify who can accept a residual limitation and how that acceptance changes the supported scope or user communication.
A responsibility map for the handover workflow
The following map is an illustrative allocation. Roles may be combined, but each decision still needs an identified owner and a route for resolving disagreement.
| Decision or obligation | Accountable role | Required contribution |
|---|---|---|
| Supported handover scope | Operations owner | Shift supervisors and technical lead |
| Meaning of maintenance evidence | Qualified domain authority | Practitioners and bilingual reviewer |
| Source access and permissions | Customer system owner | Security and integration engineers |
| Technical design and recovery | Technical lead | Application and platform engineers |
| Acceptance evidence | Evaluation owner | Domain reviewers and developers |
| Operational release | Named business release owner | Evaluation, security and service operations |
| Incidents and source updates | Service owner | Support team and source owners |
A supplier can deliver much of the engineering and evaluation work. It cannot manufacture the customer's authority to decide which maintenance information is approved or who may see it. Those responsibilities require customer participation, even when the service is externally managed.
Design the handoffs between roles
The most consequential gaps often sit at the boundary between teams. The domain reviewer reports an omission; the engineer needs a reproducible case; the source owner discovers an outdated record; operations needs to know whether to pause publication. A handoff should carry the case identifier, observed behaviour, expected behaviour, source version and urgency.
Route defects by their cause. A retrieval bug belongs with engineering; contradictory approved instructions need a policy or process owner; an unreadable source may need data remediation. Calling every defect “an AI issue” sends work to the wrong people and obscures the decision that would resolve it.
Use a shared decision log for unresolved trade-offs. Record the options, evidence, owner and next decision date. Avoid making chat history the only place where a material scope or permission change exists. The development process provides the sequence of evidence gates around these handoffs.
Scale participation with consequence and workload
A limited read-only pilot may use a small core team with part-time domain and security reviewers. A system that writes across several operational tools needs stronger integration ownership, recovery design and support capacity. These are scope-based distinctions, not universal staffing ratios.
Measure workload before adding roles. If developers are waiting for source clarification, adding another model specialist may not help. If reviewers face a growing queue, the solution may be clearer intake or narrower coverage rather than more generated drafts. Identify the constraint in the current delivery and operating process.
Make availability explicit when estimating. A specialist assigned informally to several projects may become the schedule's critical dependency. The timeline guide shows how review capacity and external approvals affect elapsed delivery even when engineering effort is modest.
Plan the team after launch before launch
Identify who owns source freshness, model changes, access reviews, incident triage and operating costs. A project team may disband, but those obligations continue. Assign a service owner who can coordinate the relevant specialists rather than expecting the original developer to remain an informal support channel indefinitely.
Handover should include a runbook, known limitations, evaluation assets, deployment and recovery procedures, and a clear account of customer versus supplier responsibilities. Confirm who can disable the agent or a particular tool during an incident and how users continue their work. If ongoing support is separately contracted, make that commercial boundary visible.
When assessing external delivery, ask for the actual allocation of responsibilities and proposed participation, not only a list of senior biographies. The partner versus freelancer guide helps evaluate how different arrangements cover continuity and specialist needs.
Make disagreement a defined part of delivery
The business owner may prefer broader coverage while the evaluation owner finds unresolved defects. Establish who decides the release boundary and what evidence they must consider. Record the accepted limitation, its consequence for users and the date or condition for reconsidering it. A meeting that ends with everyone informally agreeing to “monitor closely” does not assign the work required to manage the limitation.
For the maintenance assistant, the team might release summaries for a supported record type while withholding publication for unresolved status conflicts. That is a specific operating choice with a visible user path. It is more actionable than asking engineering to make the agent generally more confident or asking reviewers to check everything indefinitely.
Open for AI's AI agent development work can be scoped with clear customer and delivery responsibilities. To discuss the team your agent project needs, bring the workflow owner, the source-system owner and an outline of the permitted actions. The first staffing decision is which responsibilities the project actually creates.