A role is a seat,
not a persona.

Start with accountability.

A role is not a prompt trick to make the agent smarter. A role is an accountable seat.

The useful questions are concrete: what may this role decide, what belongs elsewhere, and which person answers for it?

A personality describes how an agent sounds. A seat defines what it may do.

Five things come with the seat.

1. Ownership. A decision, question or tension names the role that owns it.
2. A person answers. An agent can do the work; a named human remains accountable.
3. Routing. Questions go to the role that decides them.
4. Rules reach the actor. The agent reads the role’s applicable rules when it starts the work.
5. Authority. What may be accepted, changed or reversed follows from the seat’s rights.

These are arrangements to establish and check. They are not evidence that your agent will always act correctly, or that assigning a question automatically notifies its owner.

Try it with one task.

Choose a small piece of work your team already does. Preparing a first draft from an assigned source is enough.

1. Name the job. Say what result the role must produce.
2. Draw the boundary. Write what it may decide and what it must hand to someone else.
3. Name the person. Put one accountable human behind the seat.
4. Check the actual setup. Ask the agent to show its workspace, active role and applicable rules.

If your agent has the Product Brain CLI connected, this existing command shows its configured workspace and session context:

A role name in an answer is not proof of a correctly bound session. Verify the actual returned identity and permissions in your setup; do not give the agent another role’s credential.

Plan one handoff.

For a writing task, give the agent the source it may use, the intended reader, the result to return and the claims it must leave out.

Review the result against the source. If the draft invents an outcome or the handoff goes to the wrong owner, keep that miss visible and give the correction to the role that owns it.

Our own work has exposed that kind of miss. A role does not remove the mistake; it makes it possible to say who should fix it.

What this does not prove.

Roles do not make agents more accurate. A successful task does not establish a reliable unattended workflow. Instructions need to reach the agent, permissions need to hold and the result still needs review.

People accept purpose, vision, strategy, objectives and key results. Consequential or binding actions still need the appropriate human confirmation.