22.17 Patterns, and when to host it yourself
- Approved by
- Panaversity ·
Part E. Design. Two concepts for designing your own workers: which patterns to use, when to host the loop yourself, and the four disciplines. Then Sitting 5, the ports and shipping. Optional Task 21b builds on 22.17, and Task 21 fills in 22.18's table.
Reference at the depth of a design decision. Each pattern gets one row here, and a paragraph with its Brightline use on the companion page. Chapter 26 goes deeper into splitting work across agents.
In everyday life. A growing accounting office first hires one bookkeeper. Later it adds juniors who each take a pile of invoices, a senior who reviews the trickiest ones, a checklist that says when a month is closed, and a filing cabinet of notes for next month. Each is a choice, and each costs something. And at some size, the office decides whether to keep renting desks or buy its own building.
What you will learn. Which ways of splitting or extending one run are worth their cost, the three places a worker can run, and when to run the loop yourself.
Why it matters. Every helper, advisor or extra round spends from the same budget, and every place to run trades control for work. Choosing without a reason buys cost, not quality.
One request, start to finish. Brightline's controller asks for one thing at month end: "Tell me which open invoices are a problem, and why, with the policy line for each." The builder could leave it to one worker in one session. Or the worker could hand purchase orders to one helper and vendor notes to another, consult a stronger model before it writes the summary, and keep going until a grader agrees every invoice has a decision. Each step adds quality and cost, and every one spends from the same budget. The patterns below are the choices.
Which six patterns can a session use?
Each one spends from the session's budget. The full description of each, with its Brightline use, is on the companion page.
| Pattern | What it is | The one thing to remember |
|---|---|---|
| Several agents in one session | The worker hands parts of a task to helper agents, each with its own instructions | They share the sandbox, the vaults and the budget, and on the lab's platform a helper cannot hand work on again |
| A workflow the agent writes | A small program that runs many agents in phases, for large work with many similar pieces | Every agent in it spends from one budget, so the cap matters most here |
| An advisor | A second, more capable model the worker consults at key moments | Billed at its own model's price, from the same budget |
| An outcome | A goal and a rubric, checked by a separate grader that sends the work back for more rounds | The grader is a model, so a check by code stays the gate (22.16) |
| A memory store | Notes a worker saves and reads in later sessions | Shared data, so one store per person and company (22.11) |
| Large outputs saved to a file | A tool result too big for the model goes to a file in the sandbox | The model reads only the parts it needs (22.6) |
Where can a worker run?
Chapter 21's ladder (Figure 21.1) had four rungs: your own loop, a tool runner (a small helper that runs the loop), an agent SDK, and a hosted runtime on top. Seen up close, there are three places a worker can run, each giving you more control and more work. The first two are forms of that top rung. The third is the three rungs below it:
| Hosted runtime | Hosted loop, your own sandbox | Your own runtime | |
|---|---|---|---|
| Who runs the loop | The platform | The platform | Your program (Chapters 20 and 21) |
| Where tools and files run | The platform's sandbox | A computer you control | A computer you control |
| Who holds each person's tokens | The platform's vaults | The platform's vaults, for connector calls | You |
| Fits when | You want the least to run | Files or tools must stay on your network | Data must never leave your systems, or you need control of every step |
| What you can test | Your product's choices, and the platform's logs | Also your sandbox | Everything, including the loop |
When do you need your own runtime?
The third place is where Chapters 20 and 21 left you: the loop runs in your own program, as plain code you can read or run by an agent SDK. Most workers you sell will run on a hosted platform. You need your own runtime when:
- The data or the tools must stay where a hosted platform cannot run, or under data rules the platform does not offer.
- You need control between model calls that a permission policy cannot express, such as your own check before every tool call.
- You need a model or a runtime the platform does not offer, such as an open model on your own servers.
- The cost or speed of many runs favors running the loop yourself.
21.9's list of what an SDK still leaves to you is the trade this table shows. A hosted runtime takes over most of it (22.1). Your own runtime keeps all of it. What counts as done stays yours in all three places (22.16).
What should you not build on yet?
Some features are in a research preview inside the platform's beta, offered on request only, and are not on the exam (22.19): private connectors reached through a tunnel from inside your own network, and a "dreaming" feature that reviews past sessions in the background. Do not build a lab or a product on them yet.
At work. In Lab 22, optional Task 21b, Claude Code gives a Cedar Ridge session an outcome with a four-line rubric written by the builder as Luis, at most three rounds and a budget of $1.00. The builder reads the grader's explanation after each round.
The operating rule: add a pattern only when the task needs it, and keep every one within the session's budget. Choose where the worker runs by where your data and tools must run.
Figure 22.23. Patterns inside a session, and the three places a worker can run, rising with how much you run yourself.
Check yourself
Question 1 / 10 · drawn from 12
0 answered
The builder needs a check of their own before every tool call, which no permission policy can express. Where should the worker run?
- Owner
- Panaversity