Module 8 — The AI Agent: Governing It · Lesson 8.3
Hiring an AI Employee
Personas with a personality, a capability scope, a model and a member ACL
~12 min
What you'll learn
- Create a persona with a role, personality and scope
- Choose capability scopes narrowly and explain why that helps
- Decide who may chat with a given persona
- Recognize when a persona is worth creating and when it is theatre
The default agent can reach everything you can. That is right for a general assistant and wrong for a colleague with a job. A persona is how you create the second: a named participant with a defined remit, a defined toolkit, and an audience. Done well, personas are the single biggest step from 'we have an AI feature' to 'we have colleagues who do things'.
Creating one
Open the agent roster — reachable from the AI Agent chat header, and from agent settings. Add a persona.
You give it a name, a role title, a personality, a set of capability scopes, optionally a specific model, and a member access list controlling who can chat with it. Save, and it appears in the persona switcher.
The name and role title are not cosmetic. They shape how people address it and what they expect from it, and — for exec meetings later — they are what the persona reports as. 'Chief Financial Officer' produces different behaviour from 'Finance Helper'.
The ten scopes
Capability scopes are groups of tools, and there are ten: tasks and projects; chat and discussions; email and calendar; developer and GitHub; workflows and automations; reports and analytics; clients and deals; finance and accounting; knowledge and files; administration.
A new persona starts with four ticked — tasks and projects, chat and discussions, reports and analytics, knowledge and files. That default is not a security boundary; you can check every box before you save. It exists because the alternative — everything on — puts Administration and Finance in front of someone who has not yet decided what the employee is for.
The advice is to go narrower than feels necessary. A persona scoped to exactly its job is better at that job, because the model is not choosing among a thousand tools when twelve are relevant. Narrow scope improves quality, not just safety.
Who may talk to it
Each persona has a member access list. This is how you make a finance persona available to the two people who should have it and invisible to everyone else.
That is a real control rather than a convenience: a persona someone cannot chat with is a persona they cannot use to reach the tools it holds. Combined with narrow scopes, this is how you delegate a capability to a subset of the team without granting them the underlying access directly.
Be deliberate here. A persona with finance scope and workspace-wide access is a wider grant than most people realize they made.
Personas worth creating
The test is whether the persona has a job that recurs and a scope that differs.
Good: a support persona scoped to clients, chat and knowledge, available to the support team, that drafts responses and files issues. A finance persona scoped to finance and reports, available to two people. An engineering persona scoped to dev, tasks and knowledge.
Bad: three personas with identical scopes and different personalities. That is theatre — you have created a costume, not a colleague, and every person now has to decide which one to ask, which is a cost with no benefit.
Also bad: a persona for a job that happens twice a year. The overhead of maintaining it exceeds the value; just ask the default agent.
Personas and governance
Personas do not escape the governance model. Scope narrows what tools a persona has; autonomy level and action policy still decide what it may do with them.
So a persona with finance scope, in a workspace where the finance category is set to approve, still parks its finance actions for approval. Scope and policy are orthogonal and compose — which is the correct design, because otherwise creating a persona would be a way around the policy.
The practical implication: narrowing scope is not a substitute for setting policy, and setting policy is not a substitute for narrowing scope. Do both.
Hire your first employee
- 1
Create one persona with a real job
From the agent roster in the chat header. A job that recurs and a scope that differs from the default agent's.
- 2
Scope it narrower than feels necessary
Narrow scope makes it better at its job, not just safer — fewer irrelevant tools to choose among.
- 3
Set the member access list deliberately
A persona with finance scope and workspace-wide access is a wider grant than it looks.
- 4
Talk to it and compare with the default agent
Switch personas in the chat header. The difference in focus on its own domain is the point.
What to watch
- Personas with distinct scopes
- How many of your personas differ in capability rather than only in personality.
- Healthy signal: All of them. Identical scopes with different voices is a costume, and it costs everyone a decision.
- Persona usage
- How often each persona is actually used.
- Healthy signal: Regularly, or delete it. An unused persona is maintenance with no reader.
- Scope breadth
- Average number of scopes per persona.
- Healthy signal: Low. Our suggested shape is two to four for a specialist; a persona with all ten is the default agent with a name.
Key takeaways
- ·A persona has a personality, capability scopes, optionally its own model, and a member access list.
- ·Ten scope groups; new personas start with four ticked, which is a starting point rather than a boundary.
- ·Narrow scope improves answer quality as well as safety — fewer irrelevant tools to pick from.
- ·The member ACL is a real control: it decides who can reach the tools that persona holds.
- ·Scope and action policy are orthogonal and compose; creating a persona is not a way around policy.
Next: giving those employees standing work — runbooks, goals, and the ledger of what they are waiting on.