Lesson 2.42.4 Choosing a surface and a model

In everyday life. A family can get help at home in three ways. They can ask a helper a quick question and get the answer on the spot. They can hand over an errand, such as buying the groceries, and the helper comes back with the result. Or a live-in helper stays in the house and keeps working between requests. Many families also book a cleaner every Monday. Each visit is a new errand that the calendar starts, and the cleaner learns what happened last week from a note on the fridge. Power is a separate choice. You ride a bicycle to buy groceries. You rent a moving truck only when you move to a new home.

A worker's runtime needs include two everyday choices: the surface it works on, and the model that does the thinking. Both are replaceable. Both still decide whether the work succeeds.

A surface is one way a product runs work for you. There are three. In chat, the AI answers you in the conversation. An agent that works on its own takes a task you hand over and carries out its steps. An always-on agent keeps working between conversations. As Chapter 1 showed, a schedule is not a fourth surface. It starts the same task again at a set time. 2.1 calls what starts the work a trigger: a schedule, or an event such as a new email. The surface decides what the AI can do, which tools and machine it uses, and how long it runs.

The same chat app can be two things. When Maria named the chat window in 2.3, she meant a channel: where people reach the worker. Here, chat is a surface: the way the product does the work, by answering in the conversation.

So a worker's setup answers four separate questions. Where do people reach it? That is the channel (2.3). How does the work run? That is the surface. What starts it? That is the trigger (2.1). What can it use? Those are features such as research, a connector, a skill or code execution. Each question has its own answer, so a team chat and a schedule are not two answers to one question. The AP Worker has both: people reach it in the team chat app, and a schedule starts its weekly register every Monday.

Choose the surface by the rung

The rung is the step on Chapter 1's ladder of interaction that the work belongs to: a message, a task or a role. A message goes to chat. A task goes to an agent that works on its own. A role needs continuity, and there are two ways to get it. An always-on agent keeps one agent running between conversations. Or the role runs as a series of tasks, each started by a schedule or by an event such as a new email. Each task starts fresh and picks up from the records the last one left. That second way is Chapter 1's disposable machine with a durable record. In 2.1's terms, a Delegated AI Worker does its job as one task, through an agent that works on its own. A Standing AI Worker needs one of the two kinds of continuity. Brightline's AP Worker uses scheduled tasks: its Monday run starts fresh and rebuilds from the register and the policy.

Figure 2.5. Choose the surface by the rung. A standing role can get its continuity from an always-on agent or from scheduled tasks that rebuild from records.

Some products give each surface its own name. Others run them from one conversation and decide from your request. The dated boxes in 2.5 show both.

Add what the work needs, and choose the output by what must last

The table puts every choice in one place. Only its first three rows are surfaces. A project, a connector, a skill and research work with any surface. An artifact and a shared document are outputs, the form the result takes. A team channel is a channel, where people reach the worker (2.3).

An artifact, as Chapter 1 showed, is a result made to show other people, such as a document, a dashboard or a small tool. You keep it, change it with the assistant and share it with your team. Any surface can produce an output. A task can deliver an artifact, and you can also shape one yourself, turn by turn, in chat. On some products, a shared document is itself an artifact (2.5).

A connector links the worker to another app, such as the AP inbox or a shared drive, so it reads information where it is kept. Concepts 8.5 and 7.5 show connectors at work.

Two more features work with any surface, and later chapters teach how to use them. Memory keeps your preferences and ways of working across conversations. Concept 8.4 shows what belongs in it and what must stay out. Code execution lets the AI write and run a small program, so a total is worked out, not guessed. It checks the arithmetic, not whether each row belongs in the total, and Concept 6.4 shows how to check both.

The kind of artifact to ask for, such as a document, a slide deck or a dashboard, is part of the brief's format (5.7).

Tell close choices apart

Some choices sit close together. Each row names the right choice, the one people often pick instead, and why that one falls short.

Put each choice where it belongs

One role usually combines several of these choices, and each one has a home in the worker's Role Contract (2.6). Here is the AP Worker:

One row needs a second look. A project goes under runtime needs, not knowledge, because a project runs nothing itself: it is how one product loads the worker's standing context, and it is rebuilt if the AI vendor changes. What survives the move is what the project held — the files, which are knowledge, and the rules, which are the contract's. The skill sits outside any one project, which is why it can travel. And the register comes back as a spreadsheet file, an output, not a field in the contract.

Choose the model by trading off capability, speed and cost

Each AI vendor offers its models as a ladder of tiers. Small models are fast and cheap, and they suit high-volume, simple steps. Balanced models suit everyday writing and analysis. The most capable models handle harder judgment, and a vendor may add a top tier for long work that runs for hours. Each step up usually costs more and responds more slowly. Some models can run on your own computer instead of in a vendor's cloud (2.5). Most models also have a second control, called effort or reasoning level. Inside one model, it trades thinking time for quality. Three rules follow.

1. Start with the recommended default. Use the AI vendor's recommended default model at its default effort. For simple, high-volume steps, you can also start with a small, fast model. Move to a larger one only if it is not good enough.
2. Find the cause before you raise effort or change models. Missing information, an unclear brief or a broken tool are fixed in the brief or the setup, not with more thinking. When the model simply reasoned badly, more effort on the same model is often the cheaper fix.
3. Decide with your own test cases, not a leaderboard. Run the candidate models on the cases in the worker's evaluations, such as the fifteen-invoice test set from Chapter 1's lab. Compare their accuracy, time and cost. A full score on familiar test cases is a lab result, not proof of reliability on real work.

Figure 2.6. Choosing a model setting. Find the cause of a failure before you raise effort or move to a larger model. Keep the cheapest setting that gets a full score.

The model belongs in the Role Contract as a runtime need, not as part of the worker's identity. If the AP Worker becomes a different worker every time the AI vendor releases a new model, the definition is in the wrong place.