# 2.1 The anatomy of an AI Worker (/ai-worker-paradigm/what-is-an-ai-worker/anatomy-of-an-ai-worker)

---
type: Document
title: "2.1 The anatomy of an AI Worker"
description: "The sixteen elements that define an AI Worker, sorted into five groups, and four pairs of elements that are easy to confuse."
status: stable
order: 102.1
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-05T06:58:09Z
chapter: "02"
part: I
expert_status: required
concepts: [ "2.1" ]
last_verified: 2026-10-12
generated:
  at: 2026-11-05T06:58:09Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** A family hires a babysitter for every Friday night.
Before leaving, the parents say who she is answering to and what she must
do: dinner, homework, bed by 8. They say what she may not do: no guests, no
driving. They also say whom to call if something goes wrong, and how they
will know the evening went well.

[Chapter 1](../from-chatbots-to-ai-workers/ladder-of-interaction.md) described an **AI Worker** as a role-based AI system with
identity, responsibilities, skills, knowledge access, tools, bounded
authority, channels, evaluation criteria, and enough continuity to do
recurring work. That description is a list. To manage a worker, you need
the full list, sorted into the questions a manager actually asks. This
book uses a framework of sixteen elements in five groups. It is a
management checklist, not the only possible definition. The table fills
it in for Brightline: once the AP assistant has all sixteen answers, it
stops being "the assistant" and becomes the **AP Worker**.

| Group | Element | What it answers | AP Worker at Brightline |
| --- | --- | --- | --- |
| Who it is | Identity | Which account it acts as | Its own account, not a person's login |
|  | Role | Its job title | AP Worker |
|  | Mission | Why the role exists, in one sentence | Pay vendors correctly and on time, and never pay twice |
|  | Accountable human owner | Who answers for its results | The controller, by name |
| What it owes | Responsibilities | The recurring work it does | Build the weekly invoice register, answer vendor status questions |
|  | KPIs (key performance indicators) | How the business measures the role | Duplicate payments found, late fees avoided |
| What it works with | Knowledge | What is officially true | The approved AP policy |
|  | Memory | What it remembers from experience | Which vendors send scanned PDFs |
|  | Procedures (skills) | The steps it knows how to follow | How to check an invoice total |
|  | Tools | Systems it can call | Inbox, shared drive, spreadsheet |
| What bounds it | Authority | What it may observe, recommend, draft, execute (do it itself) or escalate (hand it to a person) | May draft, never change bank details |
|  | Escalation | When it must stop and ask, and whom | Any bank-detail change goes to the controller |
|  | Evaluations | How its behavior is tested, before and during use | The 15-invoice test set from [Chapter 1](../from-chatbots-to-ai-workers/lab.md)'s lab |
| How it runs and is reached | Channels | Where people reach it | The team chat app, the AP inbox |
|  | Triggers | What starts its work | Monday morning, a new vendor email |
|  | Runtime | What executes it | Whatever the company chooses, replaceable |

Notice that only one of the sixteen rows is the machinery. Runtime is the
last row, and its answer is "replaceable." The other fifteen are things
you can write down and keep. That is [Chapter 1](../from-chatbots-to-ai-workers/both-ai-vendors.md)'s question — what survives,
the machine or the record? — answered for workers: the worker is the
record, and any suitable machine can run it. [Chapter 4](../the-architecture-in-one-picture/worker-is-the-records.md) builds the
architecture on that idea.

In this table, skills are the procedures the worker follows. Many AI
products now let you save a procedure as a **skill**: a reusable set of
written instructions, often with example files, that the AI loads only
when a task needs it. Because several vendors read the same skill format,
a procedure written once can travel between products (2.4, 2.5).

## Two kinds of AI Worker

The same sixteen elements describe both kinds
of worker that Chapter 1 named. They differ mainly in three rows. A
**Delegated AI Worker** is briefed for one defined job: its
responsibilities are a single assignment, its trigger is the brief you
give it, and it needs little memory, because the job ends when the work
is done. A **Standing AI Worker** holds an ongoing role: its
responsibilities recur, its triggers are schedules and events, such as
Monday morning or a new vendor email, and its memory matters, because
the role continues from one week to the next. Brightline's AP Worker is
a Standing AI Worker. Its weekly register and its inbox duty never end.
Both kinds need an owner, authority, escalation and evaluations, and the
babysitter needs them whether she comes once or every Friday.

![Two kinds of AI Worker, described by the same sixteen elements but
differing mainly in three rows. Responsibilities: a Delegated AI Worker
has a single assignment, a Standing AI Worker has recurring duties.
Triggers: the brief you give it, versus schedules and events. Memory:
little needed because the job ends, versus important because the role
continues week to week. The other thirteen elements, including identity,
owner, authority, escalation and evaluations, are the same for both.
Brightline's AP Worker is a Standing AI Worker.](img/delegated-vs-standing.png)

*Figure 2.1. Delegated and Standing AI Workers differ in three of the sixteen elements.*

## Four pairs that are easy to confuse

Four pairs are easy to confuse, and each confusion causes a different
failure.

- **Tools and authority.** Tools are what the worker *can* call.
  Authority is what it *may* do. Brightline's assistant could edit the
  register, so it did. Nobody had said it must not.
- **Knowledge and memory.** Knowledge is the governed, official record.
  Memory is non-authoritative continuity: preferences, experience, where
  to look. Memory never overrides knowledge. Brightline's March policy
  copy was neither knowledge nor memory. It was a file that nobody
  managed.
- **KPIs and evaluations.** KPIs measure the business result of the
  role. Evaluations test the worker's behavior on cases with known
  answers. A worker can meet its KPIs for months and still fail a test
  case it has not seen before.
- **Identity and owner.** Identity is the account the worker acts as.
  The owner is the human who answers for it. Brightline had neither: the
  task ran as Dave, and Dave was not watching.

## The Brightline failure, shown on the anatomy

Compare the Brightline story with the table, and every failure matches a
row. The assistant had no owner, no stated authority, no escalation
rule, an out-of-date policy copy, a borrowed identity and no
evaluations. The anatomy is a checklist for exactly these gaps.

![The five groups of the anatomy, with six of the sixteen elements marked as missing or wrong at Brightline. Who it is: identity, marked "borrowed personal login," and owner, marked "no accountable owner named." What it works with: knowledge, marked "outdated policy copy." What bounds it: authority, marked "limits not defined," escalation, marked "no stop-and-ask rule," and evaluations, marked "no behavior tests." The other ten elements are unmarked. A line at the bottom reads: a capable model plus working tools does not equal a well-defined worker.](img/anatomy-failures.png)

*Figure 2.2. The Brightline failure, shown on the anatomy. Six elements were missing or wrong.*