Lesson 2.32.3 Worker, runtime and channel

In everyday life. Think of a human accounts payable clerk. Her job description stays the same when IT gives her a new laptop, and when the company adds a second phone line. The laptop is the machinery she works with, and the phone line is one more way people reach her: either can be replaced. The job description is the role. If the job description changed every time the laptop did, nobody could manage her.

The Brightline review found three people describing one assistant three ways. Each was describing a real part, but none was describing the worker.

• The worker is the role itself: what it is responsible for, what it may do, and who answers for it. It is written down in a Role Contract, owned by the company, and given a name.
• The runtime is the replaceable harness that reasons and acts. A harness is the software that runs a model in a loop with its tools. It might be a coding harness, an agent toolkit or a hosted agent service (2.5 names each AI vendor's). You have already met a runtime: Chapter 1's sandbox, born for one run and destroyed after it. The worker is the record that survives it. IT was pointing at part of the runtime when it named the scheduled task. Its schedule, Monday morning, is a trigger.
• The channel is where people reach the worker: a chat app, a team messaging tool, an office app such as a spreadsheet, email, a web portal or an API (a direct connection that other software uses). Maria was pointing at a channel when she named the chat window.

Dave's shared project was none of these. It held standing context: the instructions and files that every chat in it started from — the project's own Files section that Chapter 1 promised. Standing context shapes the work, but it is not the worker itself. And it should point to the company's governed knowledge rather than hold its own copy. Dave's project held a copy of the AP policy, and the copy went out of date without anyone noticing.

Figure 2.4. The worker is defined once. Runtimes and channels plug in and can be replaced.

Never define a worker by its runtime or its channel

This leads to the rule: never define a worker by its runtime or by its channel. Two tests check it. If you replace the runtime, the role, its intended authority and its evaluation cases must not change. The implementation does change, so you rerun the evaluations before you trust it. If you add a channel, the worker's authority must not grow. A worker that may only draft by email may still only draft in the team chat.

Before a worker joins a team channel

A channel does change who can reach the worker. In a chat app, one person gives it work and reviews what comes back. In a team channel, several people can. So before a worker joins a team channel, settle three things: who may give it work, whose approval counts, and who sees what it posts there. Its authority is the same in both.

Chapter 4 draws these layers in one architecture picture, and its dated boxes name each AI vendor's runtimes and channels.