Start agent design from a role, not a prompt. A role says what the agent is responsible for, what it may not touch, who owns it and who it answers to. A prompt only shapes how it phrases things. Scope and accountability can be certified, enforced and audited; wording cannot. Design from the role and write the prompt last.
What is the difference between a role and a prompt?
A prompt is text given to a model to steer its output. It can be long and detailed, and good prompts make a real difference to quality. But it is an instruction to the model, read by the model, and followed as well as the model follows it.
A role is a definition held by the organisation. It names a job, a set of capabilities with a depth for each, the systems the job needs, the people it hands off to, and an accountable owner. It exists whether or not any model reads it. The platform can enforce it, auditors can inspect it, and the business can approve changes to it.
| Prompt | Role | |
|---|---|---|
| Who reads it | The model | The platform, the owner, risk, audit |
| What it controls | Tone, format, reasoning style, what the model tries to do | What the agent may do, at what depth, with which systems |
| How it is enforced | By the model's compliance | By checks at the moment of action |
| What happens when it changes | Behaviour shifts, often in untested ways | A controlled change, recertified before it takes effect |
| Who is accountable | Unclear; often whoever last edited it | A named owner |
Why do prompt-first designs drift?
Prompt-first design starts with a capable model and a document of instructions, then adds tools and edge cases as they come up. Every incident produces another paragraph: "never discuss investment products", "always check the customer's address before sending a card", "if the customer mentions a bereavement, transfer to the specialist team".
Over time the prompt becomes the de facto policy. It is long, internally inconsistent in places, and nobody can say which lines are controls and which are style. Changing a line to fix one problem can shift behaviour elsewhere. The prompt has no owner in the organisational sense, because it was never designed as an organisational artefact.
Worse, prompt-level rules are only as strong as the model's adherence. A rule that holds in testing can fail under unusual phrasing or a manipulated input. A rule that matters should not depend on that.
What does a role give you that a prompt cannot?
Three things, each of which matters for a regulated business.
A boundary the platform can enforce. If the role lists the capabilities "answer statement queries" and "reissue statements" at depths 1 and 3, the platform can refuse anything else. The model does not need to remember not to process a refund; it has no route to do so.
A unit for certification. Certification works per agent, up to its role's ceiling. A role breaks the agent into capabilities, each of which can be tested on your own cases and given the depth it needs. A prompt is one undivided block, and certifying it means certifying everything at once.
Accountability that maps to the organisation. A role has an owner, just as a human job does. Standards point the same way. ISO/IEC 42001, the certifiable AI management system standard, expects defined roles and responsibilities, covered in ISO/IEC 42001 roles and responsibilities for AI agents. The NIST AI Risk Management Framework's Govern function stresses clear accountability, set out in NIST AI RMF accountability: roles and owners for AI agents. Both are easier to meet when the agent itself is defined as a role.
How does role-first design change the build?
Starting from the role reorders the work. Instead of writing a prompt and then deciding which tools to attach, you decide the capabilities, then design the tools around them, then write the prompt to explain the role to the model.
- Define the role: the job, what is out of scope, the hand-off points and the owner.
- List capabilities with depth: each thing the agent does, and whether it reads, drafts or executes.
- Design tools per capability: narrow tools that do one thing each, as discussed in how to design tools for AI agents.
- Map integrations: which systems each tool touches and how, recorded in an agent integration design template.
- Write the prompt last, describing the role in the model's terms, with no rule in it that the platform does not also enforce.
The last step is the test. If deleting the prompt would remove a control, the control is in the wrong place.
Is there a cost to designing this way?
Role-first design is slower at the start. It needs a business owner to define the job, and it forces decisions about scope that prompt-first teams postpone. Some useful behaviours that would emerge from a broad prompt are excluded because nobody put them in the role.
That cost is the point. Each exclusion is a decision someone made and can defend. For the wider architecture question, see how to design an AI agent architecture for a regulated business.
Where Pryme fits
In Pryme, Agent Studio starts from a plain-language description of the job and produces a brief built around the role: capabilities, sources and connections, each with its intended depth. Attest certifies each agent separately. The prompt explains the role to the model; the minimum chain enforces it. See the governed agentic operating system, explained.
Questions people ask
Does a good prompt still matter?
Yes. It affects the quality, clarity and tone of everything the agent writes. It should just not be the place where permissions and controls live.
Can one role be filled by several agents?
It can, for capacity or resilience, as long as each agent is certified for the role. Each deployed agent still needs its own record and its own certificate.
How detailed should a role definition be?
Detailed enough that a person reading it could say whether a given action is in scope. If they would have to guess, the role needs another line.