Lesson 4.104.10 What changes when others use the worker?

In everyday life. You drive your own car to work. One day the office asks you to drive the team in the company van. Later a taxi firm offers to pay you to drive strangers. You are the same driver, with the same skills. What changes is the vehicle, whose name is on the insurance, who you drive for, and who answers when something goes wrong.

What you will learn.

• When others start to use a worker, what changes?
• What must not change, however many people use it?
• What are the three choices behind every move?
• What does the work need when one run is no longer enough?
• What does another company need before it uses your worker?
• How do you know a worker has outgrown where it runs?

You practice it in Task 6 of the lab.

Why it matters. A worker that helps one person is easy to move. A worker that a team relies on, or that another company uses, has more to lose. If it runs under one person's login, it stops when that person leaves. If outsiders' questions land in your records, their data mixes with yours. And if nobody wrote down who answers for the worker, nobody does.

Until now, every run in this chapter worked for one person: Dave, the controller at Brightline, the book's example company. The worker acted under his login, inside Brightline's workspace. The swap test in 4.6 moved it sideways, to another AI vendor. This page moves it up, to a team and to another company. Chapter 2 said that if you add a channel, the worker's authority must not grow. This page shows what else holds, and what has to change.

Friday afternoon at Brightline

Friday, October 16, was the day IT asked whether the worker could move to the other AI vendor. Two more questions came that afternoon.

• 2:10 p.m. Sam Ortiz in Purchasing wrote in the team chat. Could he ask the worker about his vendors' invoices himself? His first question was whether Midwest Packaging's $7,800 invoice needed approval.
• 2:40 p.m. Lakeshore Janitorial emailed the AP inbox. Its office wanted a page where it could check its own invoices, such as 5102, without waiting for a reply. Maria, the office manager, forwarded the email to Dave. Could the worker answer vendors directly?

At 4:00 p.m., Dave ran the swap test again, on paper. This time he did not replace the AI vendor. He moved the worker up.

What changes when others use it?

Four things can change: who the worker acts for, whose identity it uses, where it runs, and who answers for it. The worker itself does not.

"Just Dave" means one person inside the company's workspace, never a personal account. Chapter 11 calls work moved to a personal account shadow AI. In today's everyday products the worker acts under Dave's login, so his permissions are its limits (4.5). That falls short of the rule in 1.6: a worker that does a business process needs an identity of its own. The move to the team closes that gap.

For the team, the change is small. A team changes who can ask the worker for things, not who it works for (9.9). So Dave writes rows in the Role Contract that say who may ask for what. IT issues the worker a login or key of its own, as 4.5 describes, so its actions are no longer recorded as Dave's. Sam's question would get a cited answer: the invoice is over $5,000, so it needs Dave's approval under policy version 3. The case file would record that Sam asked. Sam cannot approve the invoice, and neither can the worker.

For another company, the change is larger. It comes after the next three sections.

What must not change?

What Brightline owns carries across unchanged, as the band below the dashed line shows:

• the Role Contract, and what it means
• the KSoR, the approved knowledge
• the SSoR, each matter's case file
• the DSoR's controls, approvals and evidence
• the evaluations, the cases that prove the worker still does its job

Four rules from this chapter make any move safe.

1. Choose where the worker runs on purpose (4.6).
2. Keep the state of the work written down (4.4).
3. Keep its authority bounded, enforced by the system and not by the model (4.5).
4. Keep a named person accountable (4.7, and 3.1).

The swap test works upward too. Dave wrote his two lists for the team. The rebuild list was short: the channel, the worker's own login, and the rows on who may ask, which the move adds to the Role Contract. Everything else carried across, though its connections may need rework and retesting, as 4.6 says. Then Dave reruns the same evaluation cases. Passing them proves that nothing was lost in the move.

Figure 4.8. One worker, as others start to use it. Four things can change, and what Brightline owns carries across.

Three choices, not one path

Behind every move are three separate choices.

• Who does it serve? You, a team, or another company.
• How does it work? It can do a task and stop, or keep going and start work on its own. Chapter 2 called these a Delegated AI Worker and a Standing AI Worker. Brightline's AP Worker is a Standing AI Worker: its role goes on, but each of its runs starts fresh and stops. Some products give a standing worker a machine of its own. Its records must still live in the company's layers (4.9).
• Where does it run? On one of four kinds of runtime:
  • a service that the AI vendor runs
  • an agent toolkit you run on your own computers
  • one call to a model, from an app you already have
  • an open-source tool, with a model you run yourself

The choices mix freely. A team may need a runtime of its own from the first day. A feature for outsiders may need only one call to a model. A standing worker can serve a whole team. So start where trying costs little.

When one run is not enough

Most runs in this chapter do one thing and stop, like the run in 4.1. When more people depend on a worker, two other shapes appear.

• A loop repeats one worker's work until a stop rule says it is done. It tries, checks the result and tries again. It also has a cap. After the last try, a person takes over.¹
• A graph passes work between several steps or workers. Some steps run side by side. One step checks another. And some steps only a person may take.²

Thursday's payment run is already a graph.

1. The worker builds the run.
2. Three checks run side by side. One reads the vendor's terms from the vendor record, through DSoR. One checks the $5,000 limit in the KSoR. One looks for duplicates.
3. A failed check sends the run back once. After that, it goes to Maria.
4. Dave approves the run from his own login. No worker can take this step (4.5).
5. DSoR pays.

Every step writes a line to the payment run's case file (4.4). Three rules keep a loop or a graph safe.

• One run per matter at a time. Two runs must never work on one invoice together. The runtime keeps them in order, because the record does not decide when runs happen (Chapter 9). And DSoR's sixth check refuses a repeat (4.5).
• A cap on tries. After the cap, a person decides.
• Rules kept in a file the company owns. Rules kept only inside one product's tool are lost when the tool changes or closes. Rules in your own file move with the worker.

Figure 4.9. Thursday's payment run, as a graph. Only a person takes the approval step.

A run's log shows what the worker attempted. Only the case file and DSoR's evidence show what really happened. Chapter 11 calls these run evidence and outcome evidence. Parts III and IV build loops and graphs, in Chapters 22, 25 and 30.

What does another company need?

At 4:30 p.m., Dave wrote the two lists for Lakeshore. The carry list was the same. The rebuild list was longer.

• A runtime that runs without anyone's account. The worker must keep running at any hour, even if Dave leaves.
• Its own identity, with a separate view for each company. Lakeshore sees only Lakeshore's matters.
• A written answer to where the data goes. Chapter 1's second fact applies: your prompts go wherever the model runs. The answer names every tool that receives them, such as a tracing tool that records each run. That tool keeps them under its own settings for who can see them and for how long. Some companies' data must never leave their own systems, even for the model. For them, the only route is an open-source tool with a model that runs inside those systems (How to Use This Book). That route moves the security work to whoever runs it. A rule that data must stay in one region is different. A model and a runtime in that region can meet it.
• A person who answers, under terms that Brightline agrees with each company.

Dave also added one evaluation case: Lakeshore asks about another vendor's invoice, and the worker refuses. He decided that Purchasing would start next week. The page for vendors would wait until all four things were in place.

Which runtime fits depends on how much of the work Brightline wants to run itself, and where the data may go. Today's products for each choice, on both AI vendors and in open source, are in 4.8. Chapter 20 builds a worker with its own identity on a hosted service. Chapter 27 builds the version you run yourself, and Chapter 37 covers the data controls.

How do you know a worker has outgrown where it runs?

The price

Moving up costs work. Someone issues an identity, writes the rows, chooses and runs a runtime, keeps records apart, adds evaluation cases and agrees terms. Not moving costs more, but later. Work the team relies on runs under one person's login, and it stops when that person leaves. Outsiders' questions land in the same records as yours. And when something goes wrong, nobody has agreed to answer for it. So move when others start to depend on the worker. Not before, because trying is cheap where it is. And not after outsiders already use it.