“Role” means three different things around this product. This page is about the delivery role someone holds on a project: analyst, engineer, stakeholder. That is separate from the access tier their account holds, and separate again from who a given documentation page is written for.
Access, Briefly
Two levels, and neither decides what someone does on the project, only what they are permitted to do.
That is the whole mechanism. See User & Role Management for how it works, and Collaboration Features for inviting people and setting it.
Every account on a customer team holds the platform role User. There is a separate administrator role, but it is held by BlueGenAI staff and operates across the whole platform rather than within one organisation. It is not something a customer can hold or grant.
The Roles on a Project
This list is expected to grow as more teams use the platform. It reflects the roles seen on real projects rather than a fixed taxonomy.
Where Each Role Should Start
Customers and stakeholders
Read the specification the platform generated, and understand what it commits to.
Subject matter experts
Answer the questions the source material left open, usually the highest-value hour anyone spends.
Business analysts
Correct a generated specification, then turn it into work.
Project leadership
See the build order and track progress against it.
Engineers and developers
Inspect what was built, and connect it to your own toolchain.
AI Platform Engineers
Prompt well, and know when to revert rather than iterate.
The AI Platform Engineer
This is the primary human builder, and the name is deliberate. It describes a discipline rather than a job title, because the work does not map onto anything in a traditional delivery team. The people who do it well have a blended skillset. Technically minded, but fluent in the subject matter. They understand the domain the application serves, not only the mechanics of building one. Aware of good system design, but not carrying strong opinions about implementation. They recognise a bad structural decision when they see one, without arriving with a fixed view of how every piece should be constructed. That second half matters more than it sounds. The habits that make someone effective writing code by hand can work against them here, because the most productive instruction describes an outcome rather than a construction. Someone who cannot resist specifying the implementation gets a narrower result than someone who states what the application must do and lets the agent decide how. It is a role that suits a strong analyst who is comfortable with systems as readily as it suits a developer willing to work differently. For why the platform rewards this shape of person, see What is BlueGenAI?.Ask Mode Is Where Roles Diverge
This is the clearest case of the platform treating roles differently, and it is worth setting up properly on any project with more than a couple of people. Ask is read-only and enforced; the agent is given only the capabilities that read, so it cannot change anything even when asked to. That makes it the right access for two quite different situations. People who need information out of the build but should not change it. Stakeholders, business development, contracts. They can ask what the application does, how a rule works, or what a screen contains, and get an answer grounded in the actual code, without any possibility of altering it. Builders thinking a change through. An AI Platform Engineer can brainstorm an approach, or ask how something was built, before deciding what to do about it. Ask outlines the change; Build makes it. The practical effect is that the read-only conversation becomes the safe way for a project’s wider team to interrogate what has been built, without needing anyone to summarise it for them. See Ask Mode.Your Next Step
Give someone the right access
Inviting collaborators, roles, and who pays for their work.
Prompt well once you are in
Where detail belongs, and when to revert rather than iterate.