Part 2 · Deep Reference
The Bench and the Handshake
Role contracts, onboarding and a read-only first exercise.
Public teaching edition · 1 October 2026
The role contract
Assign one coordinator per task. It owns the outcome, the source of truth, bounded work assignments, total budget, review, authorized delivery and final status. Assign judgment workers, execution workers and reviewers according to the actual task and available capabilities.
A standing judgment brief records the adopted mission and priorities, human-confirmed relationship expectations and service levels, authority, limits, red lines and evidence freshness. Mark candidate priorities and unapproved commitments as proposed. Do not infer a person's importance from spending, reply speed or an agent's guess.
For a specific decision, provide the exact ask, recommendation, alternatives, uncertainty, source links and next permitted action. A short brief is an index to evidence, not a prohibition on reading it. Give independent reviewers the artifact and standard without coaching them toward the builder's answer.
An accepted handoff transfers responsibility. A dispatched subtask alone does not. An agent's role is limited by the task; it does not acquire permanent authority over other projects merely by coordinating this one.
Onboarding a new agent
First test what this runtime can actually read and write. Some hosted agents have authenticated connectors and filesystems; some local tools lack the needed account. Product labels cannot settle capability.
Give the worker the authoritative instructions, a narrow task and a harmless read test. Ask it to name the source revision, its role, the allowed action and what it must not do. Confirm this in a fresh task before assuming the instructions persist.
Copyable onboarding prompt, with placeholders:
You are helping with <bounded task>.
Read <authorized instructions> and <task record> first.
Use only <allowed sources and audience>.
You may <approved actions>. Do not <restricted actions>.
The acceptance test is <observable result>.
The total budget and stop rule are <limits>.
Tell me what you can actually read, the source revision,
what remains uncertain, and your first bounded step.
Do not create accounts, install tools or change permissions
unless separately authorized.
If the worker cannot access the source, supply only the approved public-safe context or resolve the missing access through the supported flow. Scheduled tasks need their own runtime-load and first-run test; an instruction used once in a chat is not proof of later activation.
Read only comparison and first exercise
Read-only comparison prompt:
Inspect this guide and the authorized description of my existing process.
Do not create repositories, install software, change settings or publish.
Compare ownership, task records, authority, budget, reviews, access,
verification, handoff and learning. Identify what already works.
For each gap, name the evidence, consequence and smallest proposed change.
Keep facts, interpretations and proposals separate.
Do not treat missing access as proof that a capability does not exist.
Return a short comparison and one low-risk first exercise.
Beginner exercise in one Claude or Codex chat:
Using only these fictional notes, draft a short training summary.
Audience: a new team member. Output: 150 words plus a fact checklist.
Notes: Example Workshop starts at 10:00; bring a notebook;
three exercises cover asking, checking and saving a result.
You may draft here only. Do not send, publish or install anything.
Flag missing facts instead of guessing. Check each claim against the notes.
Read the result yourself. Save the ask, draft, checklist, remaining uncertainty and one lesson. A second pass in the same chat is a self-check. No GitHub account or second model is required for this exercise.