Module 3 — Right Person, Right Work · Lesson 3.4
AI Employees as Assignees
When the right doer is a persona, and how to design one that earns its place on the team
~14 min
What you'll learn
- Decide whether a task belongs to a human or an AI Employee
- Design a persona's scope, ACL, and KVN so it earns its place
- Avoid the two failure modes of persona design (too broad scope, no negation)
- Use the persona's metrics surface to know whether it is producing useful work
An AI Employee in Kavanah is not a chatbot. It is a named identity with a personality block, an allowed scope of capabilities, a member ACL of who can chat with it, an optional model override, and — newly — its own KVN. Personas can be assigned tasks, called by other personas, and held to the same metrics humans are. This lesson is how to design one that earns its place on the team, and when to assign it work instead of a human.
What an AI Employee actually is
Three things stack to define an AI Employee.
Personality. The persona's behavior comes from its personality block — a paragraph or two describing how it should approach work, what voice it should use, what taste it should bring. This block is layered onto the system prompt every time someone chats with it. A good personality block is specific ('terse, prefers data over opinion, asks one clarifying question before any multi-step plan') rather than generic ('helpful and professional').
Scope. The persona's capabilities are gated by an allowed_scopes list pulled from the nine canonical scope groups (tasks_projects, communications, email_calendar, dev_github, workflows_automations, reports_analytics, crm, knowledge_files, admin — plus finance for ClearBooks-equipped workspaces). The persona can only call tools in the scopes it was granted. A persona without the email_calendar scope cannot send mail, even if asked to.
Access. The persona's member ACL — who can chat with it — restricts visibility. An empty ACL means open to all workspace members; non-empty means restricted. Workspace admins always have access. The ACL is enforced both at chat start (403 with explicit reason) and on conversation resume.
The combination is your AI Employee's job description. The personality says how it works; the scope says what it can do; the ACL says who it answers to.
When to assign a task to a persona
Three patterns make a task a good fit for a persona.
The task is well-bounded and recurring. 'Triage support email and propose responses' is bounded (clear inputs and outputs) and recurring (you would otherwise do it weekly). A persona with the email_calendar and communications scopes can run this with a Vision of 'first-pass triage that the human spot-checks before send.'
The task is research-heavy and the human's value is in reviewing. 'Summarize the last quarter's customer feedback into themes' is the kind of task where the persona produces a draft and the human's contribution is editorial judgment. A persona with the knowledge_files and communications scopes is a fit.
The task is creative scaffolding. 'Draft three project Visions for the new mobile initiative based on the customer research' is a task where the persona produces options and the human picks. The human still owns the decision; the persona owns the production.
Three patterns make a task a bad fit for a persona. Anything that requires institutional judgment the persona's KVN does not yet capture. Anything that requires accepting accountability for an outcome (consequence still flows to humans). And anything that must hit a deadline where a model timeout would be unrecoverable.
Designing the persona's KVN
Personas, like projects, carry KVN. The fields are direct: kvn_know_how, kvn_vision, kvn_negation. They are layered onto the persona's system prompt above the personality block, so every conversation runs against them.
Know-How for a persona is the explicit context it is allowed to assume. 'This persona is briefed on our auth flow, our customer roster, and our pricing.' If the persona is going to act on email, the K should also include the email surfaces it is wired to ('reads Gmail; cannot read calendar').
Vision is the outcome the persona is in service of, in one sentence. Not its tasks — its outcome. 'This persona exists so the support team can spend their day on customer conversations, not triage.'
Negation is where the persona's accountability lives. 'Never send mail to a customer without human review. Never modify a deal in CRM without explicit confirmation. Never claim certainty about pricing not on the published page.' The Negations are what make the persona trustworthy enough to delegate to.
Personas without KVN can still be useful. Personas with KVN can be trusted with much higher-stakes work.
Two failure modes to avoid
Too-broad scope. The temptation when standing up a persona is to grant every scope so it can be 'fully capable.' This is wrong. A persona with all nine scopes will, in some conversation, take an action you did not expect — because the scope catalog is large and the persona will fill its blanks with the model's defaults. The right pattern is to scope as narrowly as the persona's job demands, and to widen only when a specific gap costs you.
No Negation. A persona without explicit Negation will act inside its scope using whatever priors the model has. For mass-produced personas — 'the support triage persona' — this is the default failure mode: the persona is technically scoped right, but it does things you would not have authorized because nobody told it not to. Adding three to five specific Negations to a high-stakes persona's KVN is the single highest-leverage hardening move in the product.
Measuring whether the persona is earning its keep
A persona is earning its keep when three things are true.
The humans whose work the persona is intended to free up are spending less time on the persona's domain. If you stood up a support-triage persona and the support team's time-on-triage did not fall, the persona is not yet absorbing the work.
The outcomes the persona produces are accepted with low edit rate. Drafts the persona writes should require small edits, not rewrites. A high edit rate is the signal that the persona's KVN — usually its Negation — is missing the constraints the human ends up imposing.
The persona is being chatted with at the expected cadence. A persona nobody talks to is one of two things: scoped wrong (the work the persona could absorb is not being routed to it) or designed wrong (the team tried it once and went back to the human flow).
Kavanah's persona metrics — visible from /admin/super for workspace admins — surface each of these. The same usage-events pipeline that tracks human DAU/MAU tracks per-persona invocations, edit rates on accepted drafts, and the cost (active CPU + tokens) of each persona, so you can decide whether to keep, sharpen, or retire it.
Stand up one AI Employee deliberately
- 1
Pick the most-bounded recurring job on your team
If you are unsure, support triage or research-summary is a safe first persona.
- 2
Open the agent roster modal and create a persona
Set the personality block, the allowed scopes (narrow), the member ACL (start restricted to admins until proven), and the model override if any.
- 3
Fill in the persona's KVN
K = what context it can assume; V = the outcome it is in service of; N = at least three explicit nos.
- 4
Assign a real task to the persona
Use create_task with the persona as the assignee. Watch the result land. Edit, accept, learn.
AI Employee value tracking
- Persona-handled task fraction
- Fraction of tasks in the persona's domain assigned to the persona vs. to a human.
- Healthy signal: Trending up as trust accrues. Sudden drops point at a recent edit-rate spike or a Negation breach.
- Draft edit rate
- Average edit distance between the persona's draft output and what the human ultimately ships.
- Healthy signal: Falling over time. Rising means the persona's KVN is out of date relative to the work it is now seeing.
- Human time freed
- Estimated weekly hours the persona absorbed, computed as task estimates × persona-completed task count.
- Healthy signal: Positive and stable. The point of standing the persona up was to free time; measure whether it actually did.
- Persona invocation count
- Conversations started with the persona per week, by member.
- Healthy signal: Stable or growing. Falling invocation count is the persona being silently abandoned.
Key takeaways
- ·An AI Employee is personality + scope + ACL + (optionally) KVN.
- ·Three good task patterns: bounded recurring, research-heavy, creative scaffolding.
- ·Three bad patterns: requires institutional judgment, accountability for outcomes, hard deadlines.
- ·Too-broad scope and no Negation are the two failure modes that erode trust.
- ·Measure whether the persona is freeing the time it was supposed to free.
Capability, availability, and the choice of doer compose into the full assignment decision. The next module turns to the question every assignment carries with it: how long will this actually take, and how do we know?