5 of 5 · A working choice
Loops and skills
A harness lets a model act one step at a time. Skills give that loop the right procedure only when a task needs it.
- A loop does
- Model, tool, result, repeat
- Each lap costs
- New tokens, plus the whole context sent again
- A skill saves
- Context space and repeated instructions
A language model reads tokens and writes tokens. It cannot run a test or edit a file by itself. Software around the model, called the harness, reads the tool call that the model writes, runs the tool, and gives the result back to the model.
That cycle turns one prediction into a worker: ask, act, inspect the result, and decide what to do next. The context grows on every lap, because the tool call and its result both become more tokens.
See the loop as code
context = [system_prompt, tool_definitions, user_request]
while True:
output = model(context) # writes tokens until a tool call or an answer
if output.is_answer:
return output # the model chose to stop
result = run_tool(output.tool_call) # the harness runs the tool
context += [output, result] # both become tokens
Follow one loop
Follow three tool laps. Each time, the call and its result join the row of cards that is the context. Watch the row grow until the model writes an answer.
The context holds 3 cards: the system prompt, the tool definitions and the request.
Each lap sends the whole, growing context to the model again, and the provider bills it as input. Prompt caching can discount the repeated part, but it still fills the context window. A short tool result and an early test save tokens on every lap that follows.
Put verification inside the loop. An agent that runs the tests after each edit gets useful feedback on the next lap. An agent that waits until five files have changed must sort through several guesses at once.
Give every loop a stop condition and a budget. Without them, a model can keep finding one more check to run.
Loops that outlive the session
A scheduled loop starts with a fresh context on each run. It remembers the last run only if it wrote useful state to a file and reads that file when it starts. The harness owns the schedule. The file carries the history.
Match the check rate to the signal. If a loop checks every minute for a change that happens once a day, it pays for many "nothing changed" results. Use an event trigger when the system can send one.
Skills: procedures stored as files
Teams repeat procedures: how to deploy, how to run a difficult test suite, how to handle an incident. If every prompt carries every procedure, most of that text is useless for the task at hand.
A skill stores one procedure in a named file. The model always sees a short description of each skill. The harness loads the full instructions only when a task matches a description. In the example below, four descriptions cost about 80 tokens on every request, and one full procedure loads only for the task that needs it.
| Skill | Always in context: the description | Loaded on a match |
|---|---|---|
| deploy-checklist | Ship a service to production: gates, canary, rollback | about 1,500 tokens |
| incident-triage | Production incident: stabilize, diagnose, escalate, write up | about 1,800 tokens |
| db-migration | Schema changes: expand, backfill, contract, verify | about 1,400 tokens |
| sprite-pipeline | Make pixel-art sprite sheets with consistent frames | about 1,200 tokens |
A task such as "API errors are spiking in production" matches incident-triage. The context then holds about 80 tokens of descriptions plus 1,800 tokens of one procedure: about 1,880 tokens. With all four procedures in every prompt, it would hold about 5,900 tokens on every request. The numbers are examples.
A skill lives in a repository, so a team can review it, version it, and change it without retraining the model. The next run that matches reads the new file.
Keep each instruction in the right place. The request states today's job. Memory stores lasting facts. A skill stores a procedure that you reuse.
Try the decision
Choose where each instruction belongs. Then compare your reason with the answer.
Change the heading on this one page and check the result.
Loops and skills work together
A recurring agent combines a schedule with a skill. The schedule says when to run. The skill says which files to check, what counts as urgent, and what state to save for the next run.
Working defaults
- Write a skill when the same procedure appears a second time.
- Write a clear description, so the model knows when to load the skill.
- Give every loop a budget, a stop condition, and a check inside the lap.
- For recurring work, decide what the loop must save for its next run.