Lesson 2.62.6 The Role Contract

In everyday life. Think of a written job posting for a part-time bookkeeper. It lists the duties, the hours, who she reports to, what she may sign, and how her work will be reviewed.

The Role Contract is the portable business definition of a worker: all sixteen elements of the anatomy from 2.1, and one line for its kind, Delegated or Standing, written down on one page. It is not a legal contract.

Three properties make it useful. It is portable, because it keeps business requirements apart from implementation choices. Business systems, such as the accounting system, can be named under tools and channels. But no AI vendor or model is named outside the runtime needs. The role survives a change of AI vendor, although the implementation must be retested. It is owned, because the company controls it and can export it, rather than leaving it only inside an AI vendor's settings. And it is checkable, because every line can be tested against what the worker actually did.

# Role Contract: <role name>                 Draft <n>, <date>

## Who it is
Identity:      <the account it acts as>
Role:          <job title>
Kind:          <Delegated (one briefed job) or Standing (an ongoing role)>
Mission:       <one sentence: why the role exists>
Owner:         <a named person, and their title>

## What it owes
Responsibilities: <recurring work, one line each, and where each result is kept>
KPIs:             <how the business measures the role>

## What it works with
Knowledge sources:   <the governed record it answers from>
Memory:              <what it may remember, and what it must not>
Procedures (skills): <the steps it follows>
Tools:               <systems it can call>

## What bounds it
Authority:   <for each action: observe, recommend, draft, execute, escalate or never>
Escalation:  <when it stops, and whom it asks>
Evaluations: <the cases it must pass, and how often it is checked>

## How it runs and is reached
Channels:      <where people reach it>
Triggers:      <what starts its work>
Runtime needs: <surface; for a standing role, how it gets continuity; model and effort; with the date chosen>

## Open questions

Four checks for a first draft

A good first draft passes four checks. Every field has an entry or an open question. The owner is a person, not a team. Authority is written as verbs, one per action. And no AI vendor or model name appears outside the runtime needs. Remember that a written line states a rule but does not enforce it. Tool permissions, approval steps and tests enforce it, and Chapter 7 builds them.

The Identity line names the account the worker acts as. A task that acts as you is fine for personal work, but a worker that does a company's work needs an account of its own (1.6). Today's everyday products often act as you, so other systems record the worker's actions as yours. If yours does, write both on the line: "Today it runs under my login. Target: its own account." 2.5 names the products that give a worker its own identity today, and 4.10 shows the move.

The contract stays one page

Look again at the middle of the template. Several lines name something without holding it. "Knowledge sources" says where the worker's knowledge lives, but the policies themselves are not on the page. "Tools" names the systems, but not which files or which versions the worker reads. And "Evaluations" names the cases the worker must pass, but the cases with their known answers are kept elsewhere.

That is on purpose. Go back to the bookkeeper. Her job posting is one page. But in her first week she also gets the office manual, access to the accounting system, the instructions for each weekly job, and a few worked examples of how things are done here. The posting does not grow to hold all of that. It stays one page, and everything she works from grows around it.

A worker is the same. Everything it is run from, written down, is its specification. The Role Contract is the specification's first page: the job and its limits, and where everything else lives. The rest of the specification grows around it as the book goes on:

• Chapter 3 adds how the work is checked: review checks for the Evaluations line, and the first examples with known answers.
• Chapters 4 to 9 add what the worker runs from: the knowledge it draws on, the instructions it follows (a brief for each task, and standing instructions for work that repeats), and the inputs and tools it uses. Chapter 7 expands the Authority line into a full Authority Envelope, the exact limits of what the worker may do, enforced by permissions and approvals.
• Chapter 23 brings the whole specification together and makes it formal: precise enough to build and test the worker from.

Through all of it, the Role Contract stays one page, owned by the company. Lab 2 writes its first draft for the AP Worker.

Figure 2.7: The specification grows around the Role Contract. The contract itself stays one page.

Two contrasting workers

The AP Worker is the one worker you build in full. The two workers below have the same sixteen elements, applied to different work. The anatomy is not only for accounting.

Contrast: a compliance research worker. A manufacturer's compliance team asks the same kinds of question every week. Does this new chemical need an updated safety sheet? Which state rules apply to a warehouse in Nevada? The worker's mission is to answer those questions from the approved rules, with a citation for every claim. It is a Delegated AI Worker: each question is a briefed job that ends with its answer, so it needs little memory between them. Most of its sixteen elements are simple. It acts on nothing outside the team, so its authority line is short: it may observe and recommend, never execute. Three elements matter most. Knowledge is almost the whole job: which rules, which versions, approved by whom. Escalation is unusual, because the worker's most important skill is to abstain. When the rules do not answer the question, it says so and sends the question to the compliance lead, rather than guessing. And its evaluations test abstaining as much as accuracy: a set of questions with known answers, plus questions it must refuse to answer. It uses research for new questions and a project for the standing rules. A capable model at higher effort is worth its cost, because a wrong citation is the failure that matters. Its KPI is not speed. It is answers that are still correct when an auditor checks them. Its owner is the head of compliance, by name.

Same anatomy, different work.

Contrast: a customer support worker. An online store's support worker answers order questions by chat and email, all day. Different elements matter most here. It is a Standing AI Worker: its triggers are constant, since every new message starts work, and its memory matters, because a customer who starts in chat and then writes by email must meet the same worker, with the same history and the same limits. It has many channels. Authority is limited but clear. The worker may look up an order and explain a policy. It may execute a refund up to $50, but a larger refund or any change to an account goes to a person. Escalation must also find the customer who is angry, confused or asking for something the policy does not cover. Its KPIs are first-contact resolution, which means solving the problem the first time the customer asks, and customer satisfaction. Its evaluations replay real conversations with personal details removed, including aggressive ones. Because there are many messages and most questions are simple, a fast, low-cost model handles the everyday ones. Harder cases go to a larger model, or to a person. Its owner is the support manager, by name.

Same anatomy, different work.