# 2.4 Choosing a surface and a model (/ai-worker-paradigm/what-is-an-ai-worker/surface-and-model)

---
type: Document
title: "2.4 Choosing a surface and a model"
description: "How to choose a surface by the rung, when to add a project, a connector, a skill or research, where memory and code execution fit, how to tell close choices apart, how to choose the output by what must last, and three rules for choosing a model."
status: stable
order: 102.4
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-11-05T06:58:10Z
chapter: "02"
part: I
expert_status: required
concepts: [ "2.4" ]
last_verified: 2026-10-13
generated:
  at: 2026-11-05T06:58:10Z
  by: process:panaversity
trust_tier: unverified
build_id: sha256:46fd53c5d7ab1c14f6347908d45c9fdaecda4d914439923ee878bdcecd57803e
dirty: true
ksor_version: 0.0.60
---

**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](../from-chatbots-to-ai-workers/both-ai-vendors.md)
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](../from-chatbots-to-ai-workers/ladder-of-interaction.md)'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.

![Choose the surface by the rung. A message goes to chat, and what lasts
is the conversation. A task goes to an agent that works on its own, and
what lasts is the delivered result; a Delegated AI Worker lives here. A
role needs continuity, which comes two ways: an always-on agent that keeps
running between conversations, keeping its identity, context and activity
record with it; or scheduled tasks, where each run starts fresh and picks
up from durable records in your account. Brightline's AP Worker runs the
second way: every Monday, a fresh run rebuilds from the register, the
policy and the run history. A standing role needs continuity, not a
standing machine.](img/surface-by-rung.png)

*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).

| The work | What to use | Kind of choice | What lasts afterward |
| --- | --- | --- | --- |
| A question, a draft or an explanation you read once | Chat | Surface | The conversation |
| Multi-step work you hand over, often while you are away | An agent that works on its own | Surface | The delivered result |
| Work that continues between conversations | An always-on agent, or tasks that a schedule or an event starts, each rebuilding from records | Surface, or a task plus a trigger (2.1) | The agent's own state, or the records each run leaves |
| Work a team asks for in a shared channel | A worker in a team channel, with rules for who may give it work ([Chapter 9](../../managing-ai-workers/work-that-runs-without-you/shared-room.md)) | Channel (2.3) | Its posts in the channel |
| Work that reuses the same instructions and files | A project | Standing context (2.3) | The instructions, files and chats in it |
| Information kept in another app, such as an inbox or a shared drive | A connector | Tool (2.1) | The link. The information stays in the app |
| A procedure to follow the same way every time | A skill | Procedure (2.1, [8.5](../../managing-ai-workers/context-memory-knowledge-and-state/configure-the-workspace.md)) | The saved procedure |
| A question that needs many sources, checked and cited | Research | Built-in tool | A cited report |
| Content you keep editing with the assistant, then share | An artifact | Output | The artifact |
| A document a team edits together, with AI help | A shared document | Output | The shared document |

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](../../managing-ai-workers/context-memory-knowledge-and-state/configure-the-workspace.md)
and
[7.5](../../managing-ai-workers/the-authority-envelope/connectors-browsers-screens.md)
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](../../managing-ai-workers/context-memory-knowledge-and-state/memory-and-ssor.md)
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](../../managing-ai-workers/the-review-contract/decision-numbers.md)
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](../../managing-ai-workers/the-four-part-brief/output-format.md)).

## 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.

| The work | Use | Not | Why not |
| --- | --- | --- | --- |
| The same background and files, each time the work comes back | A project | A new chat each time | You would paste the same background again and again |
| Steps to follow the same way every time | A skill | Project instructions | Instructions hold rules that load with every conversation, such as "always cite the policy". Steps for one kind of task belong in a skill, which loads only when that task comes up (8.5) |
| Your preferences, and what earlier chats settled | Memory | Project files | Files hold stable facts, such as the approved policy |
| Information that keeps changing in another app, such as new emails | A connector | Pasting or uploading it each time | A copy is out of date as soon as the app changes |
| Many sources, checked and cited | Research | A quick web search | A web search suits one quick fact |
| A number you will report, such as a total | Code execution | The model's own arithmetic in its reply | The model can get a long sum wrong |

## 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:

| The AP Worker's choice | What it does | Role Contract field |
| --- | --- | --- |
| Chat | Drafts replies to vendor questions | Runtime needs |
| Scheduled tasks | Builds the weekly register every Monday | Runtime needs |
| Monday morning, and a new email in the AP inbox | Start its work | Triggers |
| A project | Loads the standing instructions | Runtime needs |
| The project's files | Hold the approved AP policy | Knowledge sources |
| The project's instructions | Carry the contract's rules: role, sources, limits (8.5) | Rules, from the contract itself |
| A skill: checking an invoice total | The steps it follows | Procedures (skills) |
| The AP inbox and the team chat app | Where people reach it | Channels (2.3) |
| A connector to the AP inbox, and code execution | Read the inbox; add up the register | Tools |
| Its preferences and settled questions | What it may carry forward | Memory |

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](../from-chatbots-to-ai-workers/lab.md)'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.

![A flowchart. Step 1: start with a suitable default, the recommended model at default effort. Step 2: test and score, with representative cases and clear pass criteria. Then a decision: meets requirements? If no, diagnose and fix: check the brief, data and tools, and tune effort if the model supports it. Change the model if needed, and retest at step 2. If yes, step 3: test a cheaper setting, a lower effort or a lower-cost model. If it still passes, or if there is no cheaper option, go to step 4. If it fails, keep the previous passing setting. Step 4: confirm and record. Repeat promising settings, keep the lowest-cost reliable setting tested, and record the model, effort, score, time, cost or usage, and date. A warning says one successful run is not proof of reliability, and a full lab score does not establish production readiness.](img/model-choice.png)

*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.