The Roles You Need to Run AI in Operations

When a team adopts AI workflows, the first instinct is to focus on the technology: which model, which provider, which prompts. The role question gets deferred. Someone sets everyone up as an Admin because it is easier than thinking it through, or nobody gets access to anything because nobody knows who should configure what.

Both failure modes are expensive. An over-permissioned team is a security and governance liability: anyone can change anything, and when something breaks, nobody knows who changed it. An under-permissioned team is an adoption blocker: people cannot do their jobs, they raise support requests, and the AI initiative stalls before it produces value.

DAVE's six default roles are designed to cut through both failure modes. Each role corresponds to a distinct job in an AI workflow operation. Assign the right role to the right person and the platform enforces the boundary: a workflow designer cannot accidentally overwrite an agent's system prompt, and a task operator cannot modify the workflow they are running. The permissions are enforced at both the API and the frontend, so there is no way to bypass them from the client side.

The role assignment question is worth spending thirty minutes on before anyone logs in. This article gives you the framework to answer it.

DAVE ships with six default roles. They are editable database rows, so your organisation can adjust them as responsibilities evolve. But the defaults are a well-considered starting point that covers the distinct functions in a typical AI workflow operation.

• Admin. Full tenant administration (admin:*). The Admin role covers everything: user management, provider configuration, settings, feature flags, and access to every other screen in the platform. This is the role for the person or people accountable for the platform's configuration and security posture. Keep it to the smallest number of people who genuinely need it. Two or three Admins is a common starting point: enough to avoid a single point of failure, few enough to maintain accountability.

• Create. Agent creation and editing (agents:read, agents:write). The Create role is for the people who build and maintain the AI agents that power workflows. In practice, this is usually an AI engineer, a technical product manager, or a senior analyst who owns the prompt engineering and model configuration for a given capability. Create role holders can read and write agents but do not automatically have workflow-building access.

• Curate. Workflow building (workflows:read, workflows:write, agents:read). The Curate role is for the people who design and maintain the workflow graphs that orchestrate agents into business processes. This is usually a business analyst, an operations lead, or a process designer. Curate includes agents:read so workflow designers can see and use agents, but not agents:write, so they cannot change the underlying agent behaviour. The separation is intentional: workflow design and agent design are different disciplines with different risk profiles.

• Use. Run workflow instances and complete tasks (instances:*, tasks:*, artifacts:read). The Use role is for everyone who interacts with AI workflows as part of their daily work: the operators, reviewers, and decision-makers who run instances and complete the human tasks that workflows generate. This is typically the most widely held role in a tenant. Only Use role holders can be assigned tasks, so anyone who will ever need to review an AI output or approve a workflow step needs this role.

• Reporting. View reports and audit logs (reports:read, audit:read). The Reporting role is for the people who need operational visibility without the ability to change anything: compliance officers, data protection officers, operations managers, and team leads who monitor workflow performance and review audit trails. Read-only by design: oversight does not require the ability to modify what is being overseen.

• Financial. Commercial and financial oversight of the tenant. The Financial role is for the team members responsible for billing and commercial management. Assign it to whoever owns the budget and vendor relationship for the AI workflow platform. The specific permission tokens for this role are not listed in the current help documentation: see the gap note in the report accompanying this article.

The six default roles map onto four distinct functions in an AI workflow operation. Most teams have people who span more than one function, especially in the early stages of adoption. A single person can hold multiple roles: permissions are additive.

Function 1: Platform governance. Someone needs to own the platform configuration: setting up providers, managing user accounts, configuring security settings, and maintaining the overall health of the tenant. This is the Admin role. In a small team, this is often the technical lead or the person who set up the account. In a larger organisation, it may be a dedicated IT or platform operations function.

Function 2: AI capability building. Someone needs to build and maintain the agents: the prompts, the model selections, the temperature settings, and the behaviour parameters that determine what the AI actually does. This is the Create role. In a team that is serious about AI quality, this function is owned by someone with a technical background who treats prompt engineering as a craft, not an afterthought.

Function 3: Process design. Someone needs to design the workflows: the sequence of steps, the routing logic, the human review gates, and the overall structure of the business process. This is the Curate role. The best workflow designers are usually people who understand both the business process and the AI capability well enough to connect them effectively. They do not need to be engineers, but they do need to understand what agents can and cannot do.

Function 4: Operational execution. Everyone who runs workflows and completes tasks in production needs the Use role. This is the broadest function and the most widely held role. In a team of ten, eight people might hold the Use role. In a team of a hundred, it might be ninety. The Use role is the operational layer: it is how the AI workflow platform delivers value to the people doing the actual work.

Reporting sits across all four functions as an oversight layer. Compliance officers and managers who need visibility into what the platform is doing, without the ability to change it, hold the Reporting role. Financial sits outside the operational functions, covering the commercial relationship with the platform.

A common starting configuration for a team of five to ten people:

• One or two people with Admin (and usually also Create or Curate, since small teams wear multiple hats).
• One or two people with Create, responsible for agent quality.
• One or two people with Curate, responsible for workflow design.
• Everyone with Use, since everyone will interact with workflow outputs at some point.
• One person with Reporting, for operational oversight.
• One person with Financial, for commercial management.

One of the most important things to understand about DAVE's role model is that it is not a convention or a guideline. It is enforced at the API level on every request. A user without the required permission for an action cannot perform it through the browser, through the REST API, or through an MCP tool connection. There is no client-side bypass.

This matters for three reasons.

First, it makes the role assignment decision consequential. Assigning the wrong role is not a cosmetic error: it either blocks a user from doing their job or grants them access they should not have. Both outcomes have real costs. The role assignment conversation is worth having carefully before go-live, not after the first incident.

Second, it makes the audit trail reliable. Every action in DAVE is recorded in the audit log with the user who performed it. Because permissions are enforced server-side, the audit log reflects what users actually did, not what they were supposed to do. A Reporting role holder who appears in the audit log did something a Reporting role holder is permitted to do. There is no ambiguity.

Third, it makes compliance defensible. When an auditor asks who had access to what, the answer is in the role assignments in User Management, and the audit log records every change to those assignments. The access control model is not a policy document: it is a running system that enforces itself.

Role assignments are managed at Admin, then User Management. The screen shows every user account in the tenant with their current role badges. An Admin can add or remove roles in a single edit session by toggling the badge buttons on a user's row. Changes take effect on the user's next login.

These are the patterns that cause the most friction when teams start running AI in operations.

Giving everyone Admin. It feels like the path of least resistance when you are setting up quickly, but it creates a governance problem immediately. If everyone is an Admin, there is no meaningful access control, no separation of duties, and no way to enforce the principle of least privilege. When something goes wrong, the audit log shows multiple people with the ability to have caused it. Reserve Admin for the people who genuinely need to configure the platform.

Forgetting to assign Use to task reviewers. The Use role is required to complete tasks. A user without Use cannot see the Tasks sidebar item and cannot complete any task assigned to them. In a workflow with a Human Review node, a reviewer without the Use role will cause the instance to stall indefinitely. Confirm every person who will ever need to complete a task has the Use role before the workflow goes live.

Assigning Create to workflow designers. Workflow designers need the Curate role, not the Create role. Curate includes agents:read, which is sufficient to use agents in workflows. Create adds agents:write, which allows the user to modify agent configurations. A workflow designer who can also modify agents is a separation-of-duties problem: the person designing the process should not also be able to change the AI behaviour the process relies on, unless that is a deliberate choice.

Not reviewing roles as the team evolves. Role assignments that were correct at go-live may not match job functions six months later. Someone who was a workflow designer may have moved into a management role where they need Reporting but no longer need Curate. Someone who left the organisation may still have an active account. A quarterly role review at Admin, then User Management keeps the permission model accurate and the audit trail clean. When someone leaves, set their account to inactive rather than deleting it: this revokes access immediately while preserving the audit history.

Can one person hold all six default roles?
Yes. A user can hold multiple roles simultaneously, and permissions are additive. In a very small team or a solo deployment, one person may hold Admin, Create, Curate, Use, Reporting, and Financial. As the team grows, it makes sense to distribute roles to match job functions and enforce separation of duties.

Do the six default roles cover every use case, or will we need to create custom roles?
The six default roles cover the distinct functions in a typical AI workflow operation. They are editable database rows, so your organisation can modify them as responsibilities evolve. The defaults are a well-considered starting point: most teams find they can run a complete AI workflow operation without creating custom roles, at least in the early stages of adoption.

What does a user see if they have no roles?
A user with no roles assigned sees an empty dashboard and cannot perform any meaningful action in the platform. If a new user logs in and sees an empty screen, check their role assignment at Admin, then User Management and assign the appropriate roles. Ask the user to log out and back in for the change to take effect.

How do I know which roles a user currently has?
Navigate to Admin, then User Management. The Roles column shows colored badges for every role assigned to each user. The view is available to Admin role holders only.

What happens when I change a user's roles?
Role changes are saved immediately when you click Save in edit mode, but they take effect on the user's next login. The user's active session continues with the old permissions until they log out and back in. If the new roles need to apply immediately, ask the user to log out.

Can I restrict a user to read-only access without creating a custom role?
The Reporting role provides read-only access to reports and audit logs. There is no general read-only role in the six defaults that grants read access across all areas of the platform. If your use case requires a read-only observer role across agents and workflows, that would require a custom role configuration beyond the six defaults.

Who can assign and change roles?
Only users with the Admin role can assign or change roles. The User Management page at Admin, then User Management is not accessible to any other role.