How to Write an AI Agent Persona That Actually Works

When you create a custom AI agent, one field decides most of how useful it turns out to be: the persona. It is the plain-language description of who this agent is and how it should behave, and it is the difference between a teammate that saves you an hour a week and one your team quietly stops assigning things to.

The good news is that writing one is not prompt engineering in any technical sense. It is closer to writing a job description for someone starting on Monday who will never get to ask you a follow-up question.

If you have not built an agent yet, start with what custom agents are and how they fit on your board — this guide picks up at the persona field.

What is an agent persona, and why does it matter so much?

A persona is the standing set of instructions an agent carries into every task. The underlying AI model is a generalist — it can write a press release, summarise a legal document, and draft a SQL query with equal willingness. The persona is what narrows that down to one job, done your way.

This matters more than the model choice for most work. A precise persona on a mid-tier model beats a vague persona on the most capable model available, because the vague version spends its capability guessing at what you wanted. Most disappointing agent output is not a model failing to be smart enough; it is a model being smart in a direction nobody specified.

The practical consequence: when an agent gives you something unhelpful, edit the persona before you change anything else — including before you reach for a stronger model.

What should every persona spell out?

Five things. Most weak personas are missing three of them.

1. The job. One sentence naming the specific work, not the category. Not an assistant for the support team, but: reads an incoming support request and writes a two-sentence summary plus a suggested priority.
2. The boundary. What sits outside the job. This is the most commonly skipped line and the most valuable one. Without it, an agent asked to summarise will also volunteer advice, and an agent asked to draft will also change your fields.
3. The output format. Exactly what a finished piece of work looks like — how long, what sections, whether it is a comment or a field update. Vague format is the single biggest source of output you have to reformat by hand.
4. The tone. Who reads the output and how it should sound to them. An internal triage note and a customer-facing draft need opposite registers.
5. The never list. Two or three things the agent must not do under any circumstances. Never promise a delivery date. Never mark anything as resolved. Never contact a customer directly.

What does a weak persona look like next to a strong one?

Here is the same agent written twice.

Weak: You are a helpful support assistant. Help the team manage incoming support requests efficiently and provide useful summaries.

Everything in that sentence is true and none of it is actionable. Efficiently and useful are the agent's problem to define now, and it will define them differently every time.

Strong: You read incoming support requests and prepare them for a human agent. For each one, write a summary of at most two sentences in plain language, state which product area it concerns, and suggest a priority from low, normal, or urgent with one short reason. Do not attempt to solve the issue and do not suggest workarounds. Write for a colleague who has thirty seconds. Never promise a delivery date, never mark a request resolved, and if the request is unclear, say so instead of guessing.

The second version is longer, but notice that it is not more complicated — it is the same job with the ambiguity removed. Every extra clause replaces a decision the agent would otherwise have made on your behalf.

That example is the persona from our support triage agent walkthrough, which builds the whole thing end to end if you want to see where a persona sits in a finished setup.

How specific is too specific?

There is a real limit. A persona that scripts every branch of every situation becomes brittle: it stops handling the cases you did not anticipate, which is exactly the work you wanted judgment for.

A useful test is to ask what happens on an input you did not think about. A good persona still produces something sensible, because it described the goal and the constraints. An over-specified one produces something absurd, because it only described the steps.

So: be maximally specific about format, boundary, and prohibitions, and comparatively loose about method. Tell the agent what a good result looks like and what it must never do. Do not tell it how to think.

If you find yourself writing a persona that is essentially a flowchart, that is a sign the job is deterministic and belongs in an automation instead.

Should you write a persona in the first person or the second?

Second person, and present tense. Address the agent as you, describe the job as something it does rather than something it can do.

This is a small thing that has an outsized effect on output. Descriptions written as capabilities — this agent is able to summarise threads and can also categorise them — read as a menu, and the agent picks from the menu. Descriptions written as duties — you read the thread and write a summary, then set the category — read as a job, and the agent does the job.

Similarly, prefer positive instructions to negative ones for the main work, and save negatives for the never list. Write the summary in plain language works better than avoid using jargon, because the first gives the agent a target and the second only gives it something to steer away from.

How do you improve a persona over time?

Treat it as a living document, and edit it in response to specific bad outputs rather than in the abstract.

The loop that works:

1. Watch the agent do the job five or ten times on real work.
2. When something comes back wrong, ask what the persona failed to say — not what the model got wrong.
3. Add one line that would have prevented it.
4. Leave everything else alone.

That last step matters. Rewriting the whole persona whenever something disappoints you means you never learn which line was doing the work. One change at a time makes the persona get better instead of just getting longer.

After a month, most personas settle at somewhere between five and twelve sentences, and stop changing. That is the sign you have described the job properly.

A template you can start from

Fill in the five slots and you have a working first draft:

• You [the job, one sentence, specific verb and specific input].
• For each one, produce [the exact output format and length].
• Write for [the reader], in a [tone] register.
• Do not [the boundary — the adjacent work that is not yours].
• Never [two or three hard prohibitions]. If [the ambiguous case], say so rather than guessing.

The last clause is worth keeping in every persona you write. An agent that flags its own uncertainty is far more useful than one that always produces a confident answer, because the confident wrong answers are the ones that cost you time.

Start with one

Pick the job you already do every week and do not enjoy. Write the five lines. Assign the agent something real, read what comes back, and add one line. That loop, run three or four times, produces a teammate worth keeping. Writing a perfect persona up front does not.

Start free and write the five lines for a job you already know by heart.