Tessl Academy Agent Enablement Curriculum
Reference

How a coding agent works

The model, the harness, the tools, the loop — and where skills fit in. A plain-English picture of what's actually running when you type a prompt.

If skills are the answer, you should know what they're an answer to. This page is a short, no-marketing tour of how a coding agent works, and where the parts a developer can change actually sit.

The picture matters because most of the friction around agents ("why didn't it use the skill?", "why did it loop forever?", "why is the same prompt giving different output today?") comes from misunderstanding which part of the system is doing what. Skills don't make a model smarter. They change what the model sees.

The four parts

A coding agent is four things stacked together:

  1. The model. A large language model (LLM): Claude, GPT, Gemini. Takes text in, produces text out. That's all it does. It has no persistent memory between turns and no ability to take action on its own.
  2. The harness. The program around the model. Reads files, runs tools, manages the conversation, decides what context to inject. Claude Code, Cursor, and Codex are harnesses, not models. The same model can sit inside many harnesses and behave very differently.
  3. The tools. Programs the harness exposes to the model. When the model produces a structured "I want to run read_file" message, the harness runs the tool and feeds the result back as text. Tools are how the model affects the outside world.
  4. The loop. The cycle the harness drives: assemble context, ask the model, read its reply, run any tools the model called, feed results back, ask again. This continues until the model produces an answer without a tool call, or the loop is interrupted.

Everything you do as a skill author or enablement lead is changing one of these four. Most of what you'll change is the context: what the harness assembles before each turn.

What the model actually does

This is the part most people get wrong. The model doesn't "do" anything. It's a function: text in, text out. Given the same input it tends to produce similar output, but it has no state of its own and no access to your filesystem, your terminal, your network, or anything else.

When you "ask the agent to read a file", the model is producing a string that looks like a request to read a file. The harness recognizes that string, runs the read, and pastes the file contents back into the next message it sends to the model. The model never touched the file. It only ever sees text.

This is why:

  • Skills are read every turn, not "loaded once". Every turn, the harness re-assembles the context. If a skill matches the description-routing logic, the harness includes its body in that turn's input.
  • Models don't "remember" your earlier session. Whatever the harness chooses to include in this turn's context is what the model knows. Memory is something the harness implements, and how it implements it varies hugely between agents.
  • The same prompt can give different output. Models have a randomness parameter; the same input doesn't guarantee the same output. This is why eval runs need to be averaged across multiple attempts to be meaningful.

What the harness adds

The harness is the part with the most variation and the least visibility. Two agents running the same model can produce wildly different output because the harness controls:

  • System prompt. A preamble the harness injects at the start of every conversation: usually long, often hidden, full of behavioral instructions.
  • Tool definitions. Which tools the model can call, what their schemas look like, what's described as "preferred" vs "use only when needed".
  • Context assembly. Which files are included, which skills are included, which CLAUDE.md / AGENTS.md / Cursor rules files are loaded, how long the resulting prompt is allowed to be.
  • Output parsing. How the harness interprets the model's reply: does it try to extract code blocks, run them, ask permission first?
  • Permissioning. Does the model auto-run tools, or does the user have to approve each one?
  • Memory and sessions. Where the conversation state is stored, how it's recalled, what gets dropped when context fills up.

When learners ask "why does this skill work in Claude Code but not Cursor?", the answer is almost always in this list.

The loop and where it goes wrong

A single user request can trigger many round-trips between the harness and the model. The loop ends when the model produces output without a tool call, or when something interrupts it: the user, a permission denial, an error, or a budget cap.

Common loop failures:

  • No convergence. The model keeps trying alternatives without making progress. Often a context problem: it doesn't have what it needs to know it's done.
  • Tool-call thrash. The model calls a tool, gets a result, then calls the same tool again with a slightly different argument. Usually fixed by better tool descriptions or by a skill that codifies the right sequence.
  • Premature stop. The model returns an answer before completing the work. Often fixed by an instruction in the system prompt or a skill body that lists the required steps.
  • Runaway cost. The loop runs longer than expected and burns tokens. This is what evals measure: not just does it work, but how many iterations did it take.

Skills can help with most of these by clarifying the work the agent is doing: what success looks like, what steps to follow, what not to do.

Where skills fit

A skill is a short, named piece of context that the harness adds to a turn's input when its description matches the work in front of the agent. That's all a skill is, mechanically. It is context.

This is liberating once you internalize it. It means:

  • A skill doesn't change the model. The model is the same. The harness is the same. Only the context the harness assembles is different.
  • Skill quality is measured against the context window. A 2,000-word skill that crowds out other useful context is worse than a 200-word skill that says the same thing.
  • A skill that's never loaded does nothing. The description field is what governs loading: it's the most important thing in the file.
  • The same skill works across agents because every harness exposes some way to include named pieces of context (CLAUDE.md, AGENTS.md, Cursor rules, MCP servers). Tessl translates the same plugin into each of those formats automatically.

If you remember nothing else from this page: the model reads text and produces text. Everything else is the harness. Skills are one of the ways you control what the model reads.

Where to go next