Write the job the way you would brief a new hire, then turn each verb into a named capability with a depth, a source list and a limit. The result is a candidate agent, not a deployed one. It earns the right to act by passing your past cases, and it stays at read or draft until it does.
What does a plain-language build involve, and who owns it?
A plain-language build starts from a description a manager could write in ten minutes: "Answers supplier questions about invoice status, chases missing purchase orders, and flags anything that looks like a duplicate." A large language model is good at reading that and proposing a structure. If you are unsure what the model underneath is doing, our explainer on what a large language model is covers it.
The model's proposal is a starting point. The person who owns the process owns the description and signs off the brief built from it. An engineer may wire the connections, but the decisions about what the agent may do belong to whoever would answer for a mistake.
The output has four parts: a role, the sources it may use, the systems it may connect to, and the bounds on each action. The guide to what an AI agent's role description should include sets these out in full.
What are the steps from job description to working agent?
- Person, process owner: write the job in plain words. Include what the job is not. "Does not agree payment terms" is as useful as anything the agent does.
- Agent builder, depth 1: proposes a brief. It extracts each verb ("answers", "chases", "flags") and turns it into a capability, lists the systems each one needs, and asks about anything ambiguous.
- Person, process owner: resolves the ambiguous verbs. Words like "handle", "sort out" and "deal with" hide a decision. "Handle a refund request" could mean read it, draft a reply, or pay it. Each must become one of those.
- Person, process owner: names the sources. Which policy documents, which system of record, which fields. If two sources disagree, say which wins.
- Person, process owner: sets a starting depth. Begin at read or draft. A capability that would move money or reach a customer starts at draft at most.
- Platform, depth 1: replays the candidate on your past cases. Take a set of closed cases where you know the right outcome and score each answer.
- Person, process owner: reviews the failures, not the averages. Each failure points to a gap in the description, the sources or the bounds. Fix the brief, not the model.
- Platform: certifies the agent to the highest depth it passes. Only a certified agent may rise above draft, and only up to its role's ceiling.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Write the job | Nothing | none | Owner writes it, including exclusions |
| Propose the brief | Extracts capabilities, asks questions | 1 | Owner reads the proposal |
| Resolve verbs | Lists ambiguous verbs | 1 | Owner picks read, draft or execute |
| Name sources | Proposes likely sources | 1 | Owner confirms and ranks them |
| Set depth | Nothing | none | Owner sets a starting depth |
| Replay | Answers past cases | 1 | Owner reviews failures |
| Certify | Nothing | none | Depth rises only on evidence |
Which controls keep a plain-language build safe?
The description is versioned. Every change to the job wording, the brief or the bounds is recorded with who made it. Evidence: a history you can compare against any decision the agent took.
Exclusions are enforced, not hoped for. "Does not agree payment terms" must become a missing capability, so an attempt is refused at the point of action. Evidence: refused verdicts naming the scope bound.
Sources are an allow-list. The agent may use what is named and nothing else. Evidence: each answer carries the sources it used.
Certification on your own cases. Generic benchmarks tell you nothing about your supplier base, your policy wording or your edge cases. Evidence: a scored run against your closed cases, with every answer kept.
Expiry. A certificate that never lapses describes an agent that no longer exists, because sources and policies change. Evidence: a renewal date per agent.
What should you measure?
- Questions raised at step 2. A description that produces no questions is usually too vague, not too clear.
- Failure reasons in replay, grouped: wrong source, wrong action, outside scope, should have escalated.
- Escalation rate in live use: how often the agent hands a case to a person, and whether people agree it should have.
- Draft edit rate: how often people change what the agent drafted before sending.
- Out-of-scope attempts: how often the agent tries something its brief excludes.
What are the signs it is going wrong?
The brief grows faster than the job. If every failed case adds a new instruction, the description was never clear. Go back to step 3 and rewrite the verb.
Nobody can say what the agent may not do. If the exclusions list is empty, the scope is whatever the model infers. Write it down.
The agent cites sources nobody named. That is a connection or retrieval problem, and it is a sign the allow-list is not enforced.
Depth was set on day one and never moved. Either it was set too high and nobody tested it, or it was set low and the agent never got evidence to rise. Both mean certification is not running.
The build was bought as finished. A pre-built agent still needs your description, your sources and your cases. The trade-offs in whether to build or buy AI agents apply to the brief as much as to the code.
Where Pryme fits
In Pryme, Agent Studio reads the plain-language description and assembles the brief: role, sources and connections. It produces a candidate. Attest then replays that candidate against your own cases across seven gates, and only an agent that clears them can rise above draft. How this sits within the wider system is explained in the governed agentic operating system guide.
Questions people ask
How long should the job description be?
Long enough to name every action and every exclusion, and no longer. Half a page is typical for a single role. If it runs to several pages, it is probably two or three agents.
Can the agent rewrite its own job description?
It can propose changes, at draft. A person must approve them, and the change is versioned like any other. An agent that edits its own scope is an agent with no scope.
What if the job changes after the agent is live?
Change the description, then re-certify the agent on cases covering the capabilities it touches.