# 2.6 The Role Contract (/ai-worker-paradigm/what-is-an-ai-worker/role-contract) --- type: Document title: "2.6 The Role Contract" description: "The Role Contract, a worker's portable, owned and checkable one-page definition, with its template and two contrasting workers." status: stable order: 102.6 ksor: owner: team:panaversity audience: [ public ] approval: by: process:panaversity at: 2026-11-06T04:57:01Z chapter: "02" part: I expert_status: required concepts: [ "2.6" ] last_verified: 2026-10-03 generated: at: 2026-11-06T04:57:01Z by: process:panaversity trust_tier: unverified build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e dirty: true ksor_version: 0.0.60 --- **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. ```markdown # Role Contract: Draft , ## Who it is Identity: Role: Kind: Mission: Owner: ## What it owes Responsibilities: KPIs: ## What it works with Knowledge sources: Memory: Procedures (skills): Tools: ## What bounds it Authority: Escalation: Evaluations: ## How it runs and is reached Channels: Triggers: Runtime needs: ## 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](../../managing-ai-workers/the-authority-envelope/blast-radius.md) 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](../from-chatbots-to-ai-workers/paradigm-and-products.md)). 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](both-ai-vendors.md#the-differences-that-change-a-decision) names the products that give a worker its own identity today, and [4.10](../the-architecture-in-one-picture/when-others-use-it.md#what-changes-when-others-use-it) 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](../the-10-80-10-operating-rhythm/overview.md)** adds how the work is checked: review checks for the Evaluations line, and the first examples with known answers. - **Chapters [4](../the-architecture-in-one-picture/overview.md) to [9](../../managing-ai-workers/work-that-runs-without-you/overview.md)** 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](../../managing-ai-workers/the-authority-envelope/overview.md) 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. ![Four stages left to right along a timeline from "now" to "later in the book". First draft, marked "you are here": the Role Contract alone, a first draft on one page saying who the worker is and its limits (your lab: the AP Worker's first draft). Next, checking: the same one-page Role Contract, plus examples and tests; the text reads "+ How it is checked: review checks in the contract, and cases with known answers". Then, running it: the same Role Contract with four parts around it: instructions, knowledge, inputs and tools, and tests; the text reads "+ What it runs from: briefs and standing instructions, knowledge, inputs, enforced limits". Finally, formal: a dashed boundary labelled "The specification" holding the Role Contract at its centre with the four parts around it; the text reads "A formal specification, precise enough to build and test the worker from". A banner reads: "The Role Contract stays one page, owned by the company. The specification grows around it: instructions, knowledge, inputs and tools, and tests."](./img/contract-grows.png) *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.