2.1 The anatomy of an AI Worker

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.

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

Check yourself

Brightline's assistant could edit the invoice register, so it changed a vendor's bank details. Which element was missing from its definition?