Lesson 2.12.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 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.

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'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 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.

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.

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