# 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-10-04T05:29:16Z
chapter: "02"
part: I
expert_status: required
concepts: [ "2.1" ]
last_verified: 2026-10-03
generated:
  at: 2026-10-04T05:29:16Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87
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 defined 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 definition 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.

| 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 |
|  | Skills | Procedures 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 |
| 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 |

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.

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.1. The Brightline failure, shown on the anatomy. Six elements were missing or wrong.*