Loops and Skills

Nothing in the transformer acts. It reads tokens and emits tokens, once, and stops. Everything agentic about an "agent", the file edits and the test runs, comes from a plain while-loop wrapped around that function by a piece of ordinary software called the harness. The loop is small enough to sketch in full:

context = [system_prompt, tools_schema, user_request]
while True:
    output = model(context)          # one forward pass per token
    if output.is_answer:
        return output                # the model chose to stop
    result = execute(output.tool_call)
    context += [output, result]      # both are just tokens

Two things about this loop repay attention. The model never executes anything: it emits a tool call as text, the harness runs it, and the result comes back as more text. And the context grows every lap, which means a long-running loop inherits every property of the context window covered in the first piece: the cost of re-reading grows, retrieval degrades in the middle, and eventually compaction throws away detail. Loops do not escape the window; they run inside it.

The difference between a loop that converges and one that thrashes is mostly the lap body. Verification belongs inside it: an agent that runs the tests after each edit gets steered by real feedback every lap, while one that edits five files and tests at the end has spent four laps guessing. The result tokens are the only steering input the model gets. Make them informative and the loop self-corrects; leave them silent and it drifts.

Loops also need a reason to stop. Well-behaved harnesses enforce step caps and token budgets on top of the model's own judgment, because a model that keeps finding one more thing to check will happily spend your budget being diligent. The stop condition is part of the task definition, so state it explicitly.

Loops that outlive the session

Some loops run longer than any single context: the nightly dependency triage, the agent that watches CI and files issues, the recurring cleanup pass. Two mechanics change at that scale. Scheduling moves to the harness, either a cron-style trigger that starts a fresh agent on a timer or a self-paced loop where the agent finishes a pass and schedules its own wake-up. And state must live outside the model, in files it re-reads on every wake: the weights are frozen, the old context is gone, and whatever the loop learned last night exists only if it was written down. A recurring agent without externalized state re-derives the world from scratch every morning.

The rule of thumb for pacing came up in the effort piece in another form: match the spend to the signal. A loop polling every minute for a state that changes daily burns budget observing nothing. When the harness can notify on events, event-driven beats polling outright.

Skills: procedure as files

Once agents run in loops, the same instructions start getting retyped. How this team deploys. How to run this repo's flaky test suite. The incident checklist. The obvious fix, pasting all of it into the system prompt, works and then quietly gets expensive: every request pays tokens for every procedure, relevant or never, and the pile grows until it competes with the task for the model's attention.

A skill is the packaged alternative: a named file of instructions, optionally with reference docs and scripts alongside, registered with the harness under a one-line description. The economics are progressive disclosure. The index of descriptions rides along in every context at a few tokens per skill; the full instructions load only when a task matches. A library of forty procedures costs a few hundred always-on tokens instead of forty thousand.

Because a skill is a file, it inherits everything files already do well. It lives in a repo, versioned and reviewable in a pull request. Editing it changes the agent's behavior on the next run, with no retraining and no deploy. A teammate's hard-won procedure becomes your agent's procedure by copying a directory. Compare the alternatives: fine-tuning bakes procedure into weights where nobody can read or patch it, and prompt-stuffing pays rent on every request. Files sit in the sweet spot, cheap to change and auditable by anyone who can read.

It helps to keep the three kinds of instruction distinct, because they fail differently when mixed. The prompt states the task at hand. Memory holds durable facts about this project and this user. A skill holds a reusable procedure for a kind of task. When procedure leaks into memory or tasks get baked into skills, the agent starts applying yesterday's specifics to tomorrow's work.

Loops and skills compose

The two ideas meet in the recurring agent: a scheduled loop whose body is a skill. The cron entry says "every night at two, run the dependency triage skill" and the skill says what triage means here: which manifests to check, what counts as urgent, where to file what it finds, what to write down for tomorrow's run. The schedule is configuration and the procedure is prose, both in version control and both editable in thirty seconds. A surprising amount of operational automation reduces to this shape.

Working defaults

• Write the skill the second time you type the same instructions. The first time is a task; the second is a pattern with a third occurrence coming.
• Spend effort on the description line. It is the only part the model sees when deciding whether to load the skill, so a vague description is an unreachable skill.
• Give every loop a budget and a stop condition, and put verification inside the lap rather than after it.
• For anything recurring, decide what the loop writes down for its future self. That file is the loop's memory, so give its format the same care as the schedule.

One layer sits under all of this: the harness itself, the software that owns the loop, the tools, the permissions, and the context budget. That piece is next in the series.