An agent brief template captures everything that decides how an AI agent behaves: its role, the named owner, each capability and the depth requested for it, the sources it may read, the systems it may touch, its limits, its refusals and its escalation rules. Fill it once per agent, version every change, and certify against it.
What is an agent brief for?
The brief is the single document that says what an agent is for and where it stops. It is not a prompt. A prompt is one input to a model; the brief is the specification the whole operating system enforces, from which sources the agent may cite to which actions it may take without a person. If you want the longer argument, read why the brief is where an agent's behaviour lives.
Use the template before an agent exists, while you are still deciding whether the job suits an agent at all. Use it again every time the job changes. A brief that is not current is worse than no brief, because the certificate, the audit trail and the reviewers all point at it.
For the definition and its place in a governed agentic operating system, see what an agent brief means for AI agents.
How do you fill in each field?
Write every field as an instruction someone else could check. "Handles card queries" cannot be tested. "Answers questions about card status, declined transactions and replacement cards; does not discuss lending" can.
- Role and owner. One sentence of job, one named person who answers for the agent. A team is not an owner.
- Capabilities and depth. List each thing the agent does as a separate line, with the depth you are asking for: 1 read, 2 draft, 3 execute routine work within bounds, 4 move money or take hard-to-undo actions. You request depth here; certification decides whether it is granted.
- Sources. Name each source and its provenance class. A policy document you control is different from a customer's emailed claim.
- Connections. Every system the agent calls, with read or write marked.
- Limits. Your own thresholds: amounts, counts, customer segments.
- Refusals and escalation. What it must decline, and who receives what it cannot finish.
The guide on how to write a brief for an AI agent covers the drafting technique in more depth.
The agent brief template
| Field | What to write |
|---|---|
| Agent name and version | A unique name and a version number that changes with every edit |
| Owner | Named person accountable for the agent |
| Role | One sentence: the job, for whom, in which channel |
| Out of scope | Jobs the agent must not attempt, written as a list |
| Capabilities | One line each: verb, object, depth requested |
| Sources | Each source, its owner and provenance class (sealed, signed, declared, external) |
| Connections | Each system, read or write, and the specific operations allowed |
| Customer limits | Amount, count and segment thresholds per capability |
| Refusals | Requests it must decline, with the reason it gives |
| Escalation | Triggers for handing to a person, and the named queue that receives them |
| Tone and disclosure | How it speaks, and how it tells people they are dealing with an AI agent |
| Certification reference | The certification set and the date of the last passing run |
| Change log | Date, author, what changed, whether re-certification was triggered |
A filled example: payments support agent
| Field | Sample entry |
|---|---|
| Agent name and version | Payments Support Agent, v1.4 |
| Owner | Head of Customer Operations |
| Role | Answers retail customers' questions about payments in the app chat |
| Out of scope | Lending, complaints about staff, fraud claims, account closure |
| Capabilities | Read payment status (depth 1); draft payment trace request (depth 2); resend payment confirmation (depth 3) |
| Sources | Payments policy (sealed); payment records (signed); customer statements in chat (declared) |
| Connections | Payments ledger (read); case system (write: create case only); messaging (write) |
| Customer limits | No action on payments above 10,000; no action on accounts flagged for review |
| Refusals | Will not cancel a payment; will not change payee details |
| Escalation | Fraud mention, distress, or a second request for the same trace goes to the Payments Operations queue |
| Tone and disclosure | Plain, brief; first message states it is an AI agent |
| Certification reference | Payments support set, 400 cases, last passed run on file |
| Change log | v1.4 added confirmation resend; re-certification triggered |
Notice that the agent can resend a confirmation but cannot cancel a payment. That split is written in the brief, not left to the model's judgement.
What happens when the brief changes?
Any change to capabilities, sources, connections or limits should trigger a fresh certification run before the new version goes live. Changes to tone alone may not, but record the decision either way. The process is set out in how to re-certify an AI agent after its brief changes.
Where Pryme fits
In Pryme, Agent Studio assembles the first draft of the brief from a plain-language description of the job: role, sources and connections. The output is a candidate, not a deployed agent. Attest then certifies each agent on your own cases, and the depth granted is the lower of what the agent's role allows and what the evidence supports.
Questions people ask
How long should an agent brief be?
Long enough that every field can be tested, and no longer. Most briefs fit on two pages. If yours runs much longer, the agent is probably doing two jobs and should be split.
Who should approve an agent brief?
The named owner signs it, and a second person from risk or compliance reviews the limits and refusals. For agents that touch money or customer records, record both approvals with the brief version.
Can one brief cover several agents?
No. Each agent needs its own brief, because certification, depth and the audit record all attach to a single agent. Shared sections, such as tone, can be copied in, but each copy is versioned with its agent.